John Giantsidis, president of CyberActa, Inc, wrote in the current issue of meddeviceonline: “Increasingly, digital health technologies (DHT) are becoming part of the conduct of clinical trials for pharmaceuticals and medical devices. They cover an extremely broad range of applications, including ingestible and implantable sensors, wearable devices carried by patients to measure certain health related parameters, digital/remote monitoring of drug intake, electronic signatures on consent forms, health data analytics through processing data that support bioinformatics modelling, and electronic patient diaries. The options are increasing daily.

Consequently, the FDA is taking steps to deliver on its promise to make the U.S. the center for digital health innovation by issuing a draft guidance¹ providing its recommendations to clinical trial sponsors, investigators, IRBs, and others on the use of DHTs for remote data acquisition from participants in clinical trials evaluating drugs and biological products, medical devices, and combination products. A word of caution: It is crucial for clinical trial sponsors to understand and evaluate whether their DHT meets the definition of a significant risk device under 21 CFR 812.3(m) and as such would require submission of an IDE application to FDA under Part 812 for the same clinical investigation. Equally important, sponsors would have to determine whether the DHT is a medical device (under EU MDR 2017/745) or in vitro diagnostic (under EU IVDR 2017/746).

Goals Of The Draft Guidance

FDA recognizes the large spectrum of DHTs available for potential use in a clinical trial. As such, the draft guidance outlines recommendations intended to facilitate the use of DHTs in a clinical trial and addresses some of the information that should be included in an IND or an IDE (investigational device exemption) application for a clinical investigation in which the sponsor plans to use one or more DHTs or in a marketing application that includes such a clinical investigation. The principal areas of the FDA’s draft guidance are:

• Description, selection, and rationale for DHT use in clinical trials
• Verification, validation, and usability of DHTs
• Evaluation of clinical endpoints and statistical analysis
• Risk and other considerations when using DHTs
• Record protection and retention

Description, Selection, And Rationale For DHT Use In Clinical Trials

FDA outlines the expectation that sponsors must include in their applications an explanation as to why the DHT is fit-for-purpose, and this fit-for-purpose justification is to be based on the clinical event or characteristic of the disease or condition of interest that is to be measured, the proposed clinical trial population, the design of the clinical investigation, and the characteristics of the DHT that may influence trial participant use. Sponsors would also have to evaluate whether the participant’s own DHT and/or general-purpose computing platform is appropriate to reliably collect or facilitate the collection of data during the clinical trial. It is important to note that while these points seem straightforward and clear, the draft guidance does not provide what level of evidence is required to be fit-for-purpose. As it relates to the selection criteria, FDA sets three overarching topics to be addressed in the fit-for-purpose rationale:

1. Clinical Trial Population – Education, language, age, and technical aptitude to ensure that trial participants will be able to use the DHT as intended for the purposes of the clinical trial.
2. Design and Operation of DHTs – Fit-for-purpose rationale must cover the following:
   1. Design (e.g., material, size, weight, appearance, portability) and ease of use
   2. Power needs (e.g., battery life, charging recommendations)
   3. Operational specifications (e.g., data storage capacity, frequency of data transmission)
   4. Alerts (e.g., low battery, poor signal, data not being recorded or transmitted to the server)
   5. Environmental factors (e.g., temperature) that may affect the performance of DHTs
   6. Availability and capacity of both clinical trial participant and sponsor network systems to handle the volume of data obtained from frequent or continuous recordings
   7. DHT privacy and security to prevent unauthorized access to the DHT and the data it collects.
3. Use of a Participant’s Own DHT or General-Purpose Computing Platform and Telecommunications – The fit-for-purpose rationale must consider whether allowing trial participants to use their own DHTs reduces the burden on the clinical trial participant. FDA did not outline or define “highly specialized or customized measurements,” but those would require sponsors’ DHTs. In the submission, the sponsor would have to enumerate:
   1. minimum technical specifications (e.g., operating system, storage capacity, sensors);
   2. performance specifications (e.g., precision and accuracy); and
   3. brand, model, and/or version that meet the minimum technical and performance specifications.

Verification, Validation, And Usability Of DHTs

FDA outlines that sponsors must confirm, through verification and validation activities, that their proposed DHTs are fit-for purpose. However, the terms “verification” and “validation” as used in this guidance are not the same as in 21 CFR 820.3(aa) and 820.3(z) under the QSR for devices (21 CFR part 820) or the terms “device software function verification” and “validation” as described in FDA’s own guidance General Principles of Software Validation. According to the draft guidance, FDA uses the term verification in this guidance analogously to analytical validation² and the term validation analogously to analytical validation and clinical validation.³ The draft guidance spells out considerations that would be expected in the submission regarding the validation and verification of DHT hardware, DHT software, general-purpose computing platforms, as well as interoperability of connected systems with the DHT and usability studies on the DHT. Be advised that the FDA’s expectations are that sponsors will include usability studies to confirm the suitability of the DHT and/or general-purpose computing platform for the proposed clinical investigation. The guidance establishes several criteria to be met:

1. Enroll a cohort that is similar to intended trial participants;
2. Test the ability of future participants to use the DHT as directed in the trial protocol; and
3. Assess whether users are able to enter all data before being logged out of a DHT.

The direct reference to the 2016 guidance on Applying Human Factors and Usability Engineering to Medical Devices indicates that the FDA would expect to receive from the sponsors human factors validation testing to demonstrate that the DHT can be used by the intended users without serious use errors or problems, for the intended uses and under the expected use conditions.

Evaluation Of Clinical Endpoints And Statistical Analysis

Of particular note is the proposed requirement to establish clinical endpoint or endpoints measured from data collected through a DHT, especially when justifying a novel endpoint using data captured by the DHT, where sponsors are to justify:

1. Whether the endpoint is a clinically meaningful reflection of how a participant feels, functions, or survives;
2. How the endpoint relates to other endpoints of effectiveness that have been used to support a marketing authorization for a similar indication; and
3. Whether the novel endpoint is a sufficiently reliable measure of disease severity or health status.

Similar expectations are extended to the statistical analysis plan, where the definition of the endpoints and the source data from which the endpoints are derived for each trial participant and intercurrent events that may be related to the DHT should be prespecified in the statistical analysis plan. The listed intercurrent events are:

1. Software updates that change how the data are collected or that change the algorithms used to process data
2. Software incompatibility caused by operating system upgrades
3. Trial participant error or noncompliance with study procedures using the DHT
4. DHT failure
5. Data transmission failure

Risk And Other Considerations When Using DHTs

FDA outlines three overarching risks to trial participants associated with use of the DHTs for data collection: clinical, privacy, and informed consent. It is not evident from the draft guidance whether such information is to be part of a submission or simply a documentation of FDA’s current thinking on the matter. Irrespective of the communication status, regarding clinical risks, sponsors are expected to:

1. Analyze DHTs for physical features that could cause injury to participants;
2. Evaluate likelihood of erroneous measurement, especially in situations where measurements provide feedback to modifications or changes in the administration of investigated products; and
3. Assess any cybersecurity threats that may impact the functionality and safe data storage and transmission.

In furtherance of 21 CFR 50, the clinical trial risks and the requisite information on the informed consent process, the FDA emphasizes that the informed consent process must:

1. Describe any reasonably foreseeable risks or discomforts to the subject, including reasonably foreseeable risks or discomforts related to the use of the DHT in the clinical trial.
2. How the risks most likely to occur could be mitigated should also be considered for inclusion.
3. Include a statement indicating that use of the DHT during the clinical investigation may involve risks to the subject that are currently unforeseeable.
4. Explain the type of information that will be collected by the DHT, how that information will be used and monitored and the measures to protect a subject’s privacy and data, and the limitations of those measures.
5. Specify who may have access to data collected through the DHT during or after the clinical investigation and during what time frame.
6. Understand and map the impact of each end-user license agreements or terms of service as a condition of use because they may allow DHT manufacturers and other parties to gain access to personal information and data collected by the DHT. As such, sponsors and investigators should ensure that the informed consent process explains to subjects that their data may be shared by the DHT outside of the clinical trial, according to the end-user license agreement or terms of service.

Record Protection And Retention

FDA outlines that sponsors and investigators are responsible for recording and retaining data captured by the DHT in accordance with FDA’s record retention regulations for sponsors and investigators. It also makes reference to another draft guidance, “Use of Electronic Records and Electronic Signatures in Clinical Investigations Under 21 CFR Part 11—Questions and Answers.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Peter H. Calcott, D.Phil., president and CEO of Calcott Consulting LLC wrote in the current issue of meddeviceonline:

1. Part 11 Compliance

Part 11 compliance has been around for about 20 years,¹ but still today I see confusion in the industry. While most elements have been implemented successfully, in part attributable to the array of great software available in the marketplace, there are still areas where people stumble. I will illustrate two areas.

First, while almost all my clients purchase software in the marketplace, the systems fall into two types for the purpose of this point. The systems that reside in the cloud, where you access the application via the internet, usually are very robust. However, I have seen clients disable certain features that can have impact (e.g., audit trails). On e-systems that reside on a PC at the site of use, I have witnessed several problematic incidents. These all focus on the integrity of the clock used to date-stamp data. In these examples, the software has used the Microsoft (computer) clock to date-stamp the data rather than the software clock. In both cases, the Microsoft clock was not protected, and I could change the date and time with a click of the mouse. This rendered the date stamp worthless. The simple fix was for the administrator to lock the computer setting so that analysts could not change it. Of course, the system administrator can still do that.

Second, assignment of appropriate access based on job function is critical for meeting Part 11 compliance. At larger companies, there are at least three levels of access, easily recognizable. I will use setting up access levels for a High Pressure Liquid Chromatography (HPLC) as an example. The most restrictive is for staff who simply review data, either rejecting or approving the results. This is common for supervisors or manager-level staff. The next level is assigned to analysts, where they need to be able to set up runs, review data, and make adjustments to, for instance, integration parameters. And finally, there is the system administrator, who has complete access to the inner working of the system. In some smaller companies, these assignments are often blurred, with “super users” having administrator rights although they actually run samples and process data. This means that these analysts can actually access the file systems and make major adjustments. This leads to situations where DI can be questioned. It is particularly important to assign the access based on job function and separate the administrative functions from analyst roles. This tends to be a problem particularly in smaller companies.

2. Integration Of HPLC Chromatograms

Ideally, software should be set up to run automatically and integrate correctly every time. However, in many analyses, integration is not perfect, requiring post-analysis adjustments. If this is the case, it is paramount to incorporate into the method SOP a procedure to follow, with appropriate documentation, so the reintegration is performed in a reproducible compliant and documented manner. Without these controls and checks, it leaves the company open to DI questions.

3. Out Of Specification (OOS) Investigations

Even after the “Barr Case” of 1993,² companies run into problems with how they conduct OOS investigations. There needs to be a robust SOP detailing how you proceed when a suspected OOS is encountered. Initially, before any investigation into product quality, there needs to be an assessment as to whether the method was run correctly in the laboratory. If an error can be demonstrated, the whole result or even the whole run can be nullified and the run or sample repeated. Once the run is shown valid, or at least cannot be nullified, then a product investigation can be considered. A detailed investigation plan, including repeat testing or retesting, must be drawn up and executed. Failure to follow a structured plan can create doubt about your DI status and conclusions.

4. Environmental Monitoring (EM) Data

Particularly in sterile or aseptic processing operations, many EM data are generated and analyzed. Obviously, the correlation between numbers of colonies on plates and the results on test forms must be perfect. So, when I routinely audit operations, I often review these forms. Even well-run operations will pick up counts on plates quite normally. If I see page upon page of zero colony forming units, my suspicions are triggered. If it looks too good to be true, it usually is.

5. Reports That De-emphasize Data That Compromises The Study – Validation And Investigations

As I indicated in part 1 of this article series, any discrepancy or deviation or anomalous data that is generated in an investigation or validation must be considered in the context of the end result of the report. Too many times, I have found results that might cast doubt on a conclusion are ignored and not discussed. Not all “failing” results or deviations will necessarily nullify the conclusion. In many cases, other tests can be performed to address the anomaly. At the end of the day, you want a report that can be read by others (including an inspector) that is correct and convincing.

6. Cherry-Picking Data

In many MHRA and FDA presentations and guidances,^3-7 they have described cherry-picking of data. That is the tendency to keep testing until you get the result you “want” – usually a passing result. It often manifests in using unofficial databases to house data, running trial samples, using test samples to “calibrate” systems, and the list goes on. In the GMP world of validated methods, you get a chance to run a sample once according to the SOP. Only if you can prove there was a lab error can you justify nullifying the test and repeating it. While FDA warning letters are rife with incidents, I have found in auditing it often happens in smaller companies that are transitioning from being solely a research company to a development company moving into clinical trial manufacturing. Often, the senior staff is research trained and not familiar with the GMP requirements. It is a hard transition to make in a career. I know because I made that transition a long time ago.

7. Making Data And Sampling Ports Accessible

Although I have never seen an example of this in my years of auditing, I am including it because the MHRA used this example in its 2018 guidance ⁶. By this, they mean that a sampler might be tempted to sample not from the correct port in, for instance, a WFI loop, but rather another from a more accessible one, if the former is difficult to get to. So, we must be vigilant to assure we do not install obstacles in the way of our staff getting their jobs done correctly.

8. QA-Issued Forms

Any blank form used in your operations (on the shop floor or QC labs) must be a controlled form. That is, it must be QA issued (appropriately reviewed and approved) and be issued with a unique identifier. QA needs to keep an inventory of those issued, when, and to whom. If the forms are available online and can be printed off by an operator, then the control is lost. A form can be filled in or destroyed with no record. I have found this is a difficult principle for some smaller companies to grasp. If you do not track issuance of your forms, you are open to questions about the integrity of your documentation.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Sara Cinnamon, Amy Hung, Tobias Silberzahn, and Eli Weinberg (McKinsey) wrote in the current issue of meddeviceonline: “While wearable medical devices offer the opportunity to monitor, diagnose, and deliver individualized care to patients, adoption by clinicians has yet to gain significant traction. However, the COVID-19 pandemic has raised awareness of wearables and how they can provide clinical benefit in a remote setting. Many medical practitioners and patients were introduced to new ways of delivering care, including expansion of existing telemedicine and remote patient monitoring.

Traditionally, mainstream wearables familiar to consumers were not developed with clinical rigor from the outset. Medical devices have a high bar for accuracy and validation to integrate and deliver the type of data required for clinical use within the healthcare delivery ecosystem. Consumer devices often leverage less-accurate sensors or inferred measurements to support informational and non-medical feedback to the user. Seeing the evolving remote care trends and revenue potential of clinical use, consumer device makers have begun closing that gap. For example, Apple has received FDA clearance for the ECG function on the Apple Watch, opening the door for its use in clinical settings. Oura, maker of a smart ring that senses activity, sleep, body temperature, and heart rate variability, has partnered with UCSF to create an in vivo trial to rapidly collect correlative data between biomarker changes and COVID-19 diagnoses to inform a diagnostic algorithm.

In fact, research shows the wearables market is estimated to grow considerably, with 19 percent CAGR from 2020 to 2030, representing potential economic value of $0.5-$1.8 trillion by 2030. This growth includes consumer, industrial, and medical applications, but market activity indicates significant promise (and movement) in the healthcare domain:

• In 2020, global shipments of hearables, watches, wristbands, and other wearables stands at 444.7 million units
• Investors have committed more than $400 million to wearables-focused startups since 2015
• Large medical device companies are acquiring smart devices, such as Stryker’s acquisition of OrthoSensor and Boston Scientific’s acquisition of Preventice Solutions
• Academia continues to drive innovation in ever smaller technology, with advances in implantable chips from UC Berkeley, flexible batteries from Stanford University, and flexible sensors from the University of Illinois at Urbana-Champaign

Device manufacturers are well positioned to capitalize on this unique opportunity. However, to deliver devices useful for clinicians and patients, wearable technologies must advance further. Breakthroughs in healthcare will likely come from devices that not only accurately measure disease-specific biomarkers at home but also provide real-time contextual data on other features that affect disease management. These insights must be shared via a simple user experience to encourage patient adoption and must demonstrate improved medical care and reduced costs to providers and payers.

Based on our experience, wearable device manufacturers and service providers should focus on three areas to ensure success in the market:

1. Meeting and exceeding user needs
2. Delivering rigorous, compliant data and insights for the entire patient care ecosystem
3. Crafting a viable business model

Here, we provide an overview of each focus area. In future articles, we’ll dive more deeply into each.

1. Meeting And Exceeding User Needs

Patients and clinicians expect sufficient long-term benefits in exchange for using wearable devices, what can be called “return on engagement.”

For patients, return on engagement translates into benefits such as reassurance that a professional is monitoring them and able to deliver care above and beyond what point-in-time visits can offer. They expect this to come with minimal discomfort from the ongoing use of these devices. If the device is uncomfortable or creates substantial burden on patients’ daily routines, they won’t use it. As a result, strive to develop smaller, less obtrusive devices with longer battery life. Device designers must also understand how physical and cognitive ergonomics affect device operation and data comprehension. Patient interactions with the device should be simple, seamless, engaging, and personal.

Clinicians’ return on engagement can be realized by integrating device read-outs into their current systems and workflows seamlessly, as well as by generating insights that they wouldn’t be able to infer otherwise. Devices and associated services that combine wearable data with real-world data sources to reveal patterns and trends will give clinicians a more comprehensive picture of patient health compared with point measurements in the doctor’s office, enabling more efficient disease management.

For both clinician and patient, safety, data security, and efficacy are table stakes, with correlation to better patient outcomes the ultimate sign of success.

2. Delivering Rigorous, Compliant Data And Insights For The Entire Patient Care Ecosystem

The data collected by wearables must be sensitive, specific, clinically validated, and offer more than that available through current standards of care. Such rich data will enable a better understanding of disease progression, more precise patient segmentation, and, ideally, better clinical outcomes.

However, the data alone won’t provide this level of value. Wearables must also deliver a level of contextualization and analysis that requires robust algorithm development hand-in-hand with device development (e.g., to accommodate individual variations and provide clear clinical insights). These insights must then be visualized and displayed in a way that is easy for users to comprehend and act upon.

Device makers must also consider the needs and requirements of other stakeholders in the patient care ecosystem, including payers, hospitals, and regulators. Data serves as the connective tissue that enables this ecosystem to better work together for the good of the patient, making it critical that these stakeholders can share and communicate the data and insights seamlessly. Industry standard protocols such as FHIR or HL7 enable interoperability to ensure all stakeholders have access to the right information at the right time. As a result, consider how your device’s data will be transferred to the electronic health record for clinician review or how it will interact with third-party APIs.

Finally, data storage and transfer must comply with industry regulations — such as HIPAA, GDPR, PIPEDA, and CCPA  — and best practices for privacy and security. For instance, use industry-standard encryption for data on devices and during transmission, and prevent or mitigate unauthorized access to devices, smartphones, and servers. As regulations evolve, such as with the European Commission’s recently announced legal framework for trustworthy AI, so must manufacturer approaches.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

The regulatory and quality landscape for medical devices is constantly evolving. The mission of MedSysCon is to deliver specialized consultancy services for regulatory affairs and quality assurance, focused on the digital health industry.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Jim Kasic, founder and chairman of Boulder iQ, wrote in the current issue of meddeviceonline: “Say “start-up” in the medical device community and the conversation can move quickly to funding. Who will invest? How much? How long will it take?

A particularly tough challenge for medical device start-ups is that the executives tend to be the scientists and inventors of the device. When it comes to funding, you need to trade your inventor hats for business ones and learn to think like an investor. It’s not an easy task, and with most medical device start-up companies operating in a very competitive landscape, the need for speed in attaining this business acumen is critical.

How to do it? Here are five tips to help a medical device start-up be more interesting, more attractive, more investable – and less risky – to potential funders.

1. Define your market.

In other words, do your competitive homework. As wonderful as you believe your device is, make sure you have something new, something that performs a function at a lower cost than existing devices, or offers more for the same cost. If you can prove this, and communicate it clearly, you may have an attractive investment.

A market that is eager for a device to answer a clear unmet need is the optimal “defined market.” Investors want to see that your device fits clearly into a specific medical treatment area or diagnostic process and that it enhances or replaces current procedures. In the medical device start-up world, there is no place for “missionary” sales work, where you must convince a customer to believe in a new product concept – especially one that requires a change in current procedures. This process, which is incredibly difficult to carry out, also is long and involved – none of which works for an investor looking for timely returns.

• Create a device that will be used in procedures that are already being performed.
• Make sure the device will be used in a specific application.
• Define the physicians or other clinicians who know they need a new or improved way to perform the procedure.
• Calculate the market size. This could be based, for example, on the number of specific surgeries conducted each year that will use the device, or other relevant use factor.
• Know how to identify where the users are and how to reach them.

2. Make sure that your market will be willing to accept and pay for your device.

Investors want to make sure that buyers will be willing to accept and pay for your device. So, while medical device developers all want to create devices with clinical benefits, they must also have economic benefits.

Once ready for market, the reality is that a purchasing agent must deem your device necessary and affordable. Even if a physician requests it, the purchasing department has to make sure that the device satisfies the physician’s need at the lowest cost. One way to help assure this acceptability is to demonstrate that your device can be paid for within current reimbursement structures, specifically through Diagnosis-Related Group (DRG) reimbursement and Current Procedural Terminology (CPT) codes.

A DRG reimbursement is associated with a patient’s diagnosis, which typically is associated with a fixed dollar amount of reimbursement – i.e., a DRG reimbursement. The healthcare provider is expected to treat the diagnosis for this fixed amount. If your device can help them do that for less money, you may have an advantage in that provider’s system.

CPT code reimbursements are associated with a physician’s specific skills and their use of equipment and tools to perform a particular procedure. For example, physicians performing cardiac catheterization procedures require special training and qualification. The CPT code provides additional reimbursement for the special skills and equipment necessary to perform this treatment. Medical device entrepreneurs should understand that obtaining new CPT codes is a lengthy process typically requiring two or more years, along with several peer-reviewed publications attesting to a device’s advantages. However, if your device fits within existing CPT codes, you will have a clear economic advantage in investors’ eyes.

3. Set a price that supports high margins.

Investors are looking for a solid story of why you can expect high margins and how you will maintain those over a reasonable period of time.

Medical device values are based more on the importance they bring to a particular procedure than on manufacturing costs. Devices that offer a truly unique market advantage and provide excellent value to each of the “3 Ps” (the patient, the physician, and the payer) are in the best position to support high margins.

Gross margin is calculated as:

(Average sales price – Cost of goods sold) x 100

Average Sales Price

Gross margins above 70% are typically attractive to investors. A gross margin in the mid-80% range offers excellent returns. Investors also understand that these high gross margins are needed to support the overhead costs of working and innovating in a regulated industry.

Investors will want to see pricing that is commensurate with those margins. Think of it this way. In the early and mid-1900s, there was such a thing as “penny candy.” It was fun for kids to buy, but no matter how high the gross margin was on a piece of candy, the manufacturer was never able to make a significant amount of money on that product alone. The selling price was just too low.

In the medical device community, developers can look at the number of procedures performed each year that would employ their devices. Very few medical procedures are performed to the tune of millions per year, but it’s very possible that a device would be needed for hundreds or tens of thousands of cases per year. If so, there’s likely an opportunity to make a device that can be produced in a large enough volume to support high margins and command a price that will provide sufficient returns to investors (and the developer).

Setting sales prices encompasses far more than the cost of making them and obtaining required regulatory and quality certifications. Medical device developers may overlook the real costs of marketing and selling as they analyze margins and pricing. Consider that there is substantial cost in communicating to potential buyers and convincing those buyers – usually physicians and payors – to purchase the device. You must balance the cost of obtaining a customer with your gross margin and number of devices a customer is going to buy.

For example, you want to make sure that the margins on the device can cover the sales and marketing costs. Imagine a device is sold for $2,000 with an 80% margin – meaning the company would make $1,600 on the sale. But that’s before overhead costs that include sales and marketing. If those costs are $5,000 – not unrealistic – then the company will not make any profit, and in fact, will lose money on the deal.

However, if a customer buys four devices, the company would be making a total gross margin of $6,400. Subtract that $5,000 cost for sales and marketing, and now you are covering the cost of converting the prospect into a customer as well as starting to create a positive cash flow.

Conversely, let’s say you have a less expensive device that sells for $1,000. At that price, you’ll need to sell twice as many to cover the cost of converting a prospect into a customer. The bottom line is that start-up device developers must do the math, be realistic, and understand the importance of pricing to investors.

4. Confirm your FDA pathway.

Regulatory hurdles can present some of the greatest risks for investors interested in start-up medical device businesses. Sadly, horror stories abound about companies that were convinced they had a clear FDA pathway and later found otherwise. Hopeful investors and investment dollars went by the wayside.

For example, a client of ours was developing a drug delivery device, which it considered  a simple pumping or transfer mechanism. Far along in the product development cycle, they learned that the FDA classified the device as a “combination product” and required proof that the drug container provided long-term stability for its contents. As a result, instead of looking to obtain a 510(k), the company faced lengthy, expensive drug storage testing to confirm that the device had no adverse effect on the drugs it would deliver.

Other examples include devices that try to combine predicates in a 510(k) application, when the devices actually have separate indications of use. Instead of a 510(k), a lengthier and more involved de novo application might be required.

Medical device start-ups should also be aware they may be required to conduct clinical trials to help establish a device’s safety and efficacy. They would then need to submit a Clinical Evaluation Report (CER) with appropriate statistical evaluation of the results with their 510(k) application. Some 510(k) devices are cleared without clinical data requirements, but not all. To assume that no clinical data will be required can lead to a grossly underestimated timeline and budget, which translates to poor investor returns. The best advice is to check it out in advance, consulting with industry experts or the FDA if needed.

The bottom line is to never assume a simple path to regulatory clearance. While some cases may be straightforward, it is almost always advisable to take the time to get an opinion from a regulatory affairs professional or ask the FDA to classify your device by submitting a 513(g) application.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Hearables – The Next Revolutionary Medical Devices

A conversation with Jacob Skinner, Ph.D., CEO, Thrive Wearables presented in meddeviceonline.com gave insights into a new category of medical devices: “

Hearables, in-ear devices that use sensors to monitor health, are on the brink of becoming the next revolutionary technology. While in-ear devices have been around for decades in various iterations (used primarily for transmitting sound), the application of this technology in the medical field is a relatively new area to explore. Jacob Skinner, CEO of U.K.-based wearable technology design and development consultants Thrive Wearables, discusses its possibilities.

Why Are Hearables Becoming More Important As A Technology Now?

Skinner: In recent times, sensor technology has shrunk significantly so that all kinds of capabilities can be added to in-ear devices, creating a subcategory of wearable technology that we call hearables.  Additionally, most of us carry a supercomputer around in our pockets, which can process data sent to, and received from, in-ear sensors.

JacobTechnology for transferring information is getting better, too. Early Bluetooth headphones traded audio quality for convenience, but today’s wireless earphones are good enough for all but the most dedicated audiophile. Last year, a new standard, Bluetooth LE Audio, was announced that can support hearing aids, streaming to multiple devices, and the Low Complexity Communications Codec (LC3, which transmits at lower bit rates, meaning that the device can use less power and can be less bulky).

In addition, almost all of us use earphones of some kind, whether they are wireless, Bluetooth-connected, in-ear buds, or wired headphones that go over the ear. We’re all pretty comfortable with the technology, which helps with patient adherence of this burgeoning field. So, the reason hearables are growing now is a combination of a form factor that we’re all used to and improvements in technology that enable us to make earphones do more than ever. It’s common for wireless earbuds to have a microphone, for example, and a sensor that stops playback when an earphone is removed from the ear. But we are now seeing them become health and fitness devices.

What Can Hearables Bring To The Health And Wellness Space?

Skinner: Some of this technology will simply offer an improved listening experience, based on individual circumstances, and some products are merging traditional ear device uses (listening to music or phone calls) with medical uses. EVEN’s headphones and Nuheara’s IQbuds, for example, both adapt their output to boost frequencies the listener doesn’t hear so well. Everyone’s hearing is slightly different, so compensating for personal limitations or age-related hearing loss can help.

Other technologies use earphones to monitor activity, stress, and even the brain. Sensors can be used for photoplethysmography (PPG), which is the use of light to detect changes in blood volume. That can tell you things like oxygen saturation (SpO2), blood pressure, and pulse rate. Blood pressure is a good measure of overall health, while SpO2 can monitor lung conditions, sleep apnea, and patients with cardiac conditions, among other things. Analyzing changes in this data could provide early indication of heart or blood pressure problems, as well as things like stress or drowsiness.

We can measure heart rate variability, too, which is the time difference between heart beats. A heartbeat of 60 beats per minute is not literally one beat every second. The gaps between beats will vary and the greater the variability, the better condition you are in. Using an in-ear sensor to measure this can help track overall fitness or recovery from a heart procedure.

Another way to monitor heart activity is with electrocardiography (ECG) sensors, which track electrical impulses, while electrodermal activity (EDA) sensors can be used to analyze breathing patterns. Electroencephalography (EEG) sensors, like those in the Kokoon sleep headphones, use electrical signals to monitor brain activity; Kokoon uses the information from its sensors to play white noise for those with trouble sleeping (Kokoon recently won a Red Dot Award in the Product Design category from Red Dot GmbH & Co. KG). Brain monitoring is developing rapidly and could be used to monitor stress, epilepsy, or even complex mental illnesses.

These are far from the only options. Temperature, motion, and other metrics can all be gathered from hearables. Electrical signals can track eye movement, which offers a way to monitor attention and alertness. Measuring changes in the shape of a user’s ear canal can identify facial expressions, which could become a means for controlling these devices or play a role in mood tracking.

What Can We Learn From That Data?

Skinner: Hearables can be useful for telling us what is happening in the body right now. They could tell you whether you are within the correct heart rate range for your exercise plan, for instance, and use an audible signal to tell you to speed up or slow down.

But trend data can be even more useful. Once a system begins to understand what is normal for your body, it can use anomalies to detect potential health problems. Combining several measures, along with things like voice recognition and head movement, could be a powerful indicator of overall health and well-being. Abnormal data could trigger anything from recommended deep breathing exercises for stress relief to scheduling an appointment with a clinician based on emerging cardiac symptoms.

When many people use these devices, their data can be analyzed in aggregate – with appropriate privacy controls. That would allow artificial intelligence and analytics to look for patterns and draw conclusions beyond those that can be derived from individual data. We might identify new warning signs of heart disease, for example, based on data collected from millions of people before they showed any symptoms.

Many of these applications are some time away from being reliable and widely used, but the pace of innovation is fast and increasing. We are just a few years away from widespread consumer use of hearables for health monitoring, but specific, niche medical uses are already happening.

Why Are Hearables Ideal For Data Collection Rather Than Wrist-Based Wearables, And What Are The Technological Challenges?

Skinner: Wearable tech for health and wellness has so far focused on wrist-based devices. However, signals from the ear are as much as 100-times clearer than those from the wrist. The inside of the ear is dark, closer to the body’s core, and the arteries are nearer the surface of the skin, which makes heart rate monitoring easier.

On the wrist, in contrast, sensors must work around muscles and tendons. During exercise, people tend to move their wrists a lot, while their heads stay relatively stable. Wrist-based monitors shine a light into the skin to detect blood flow, but if the device isn’t fitted snugly to the wrist, light can get in and reduce the effectiveness of the sensor. And unlike the inner ear, the wrist gets sweaty, which can make it hard for sensors to capture a good signal, resulting in variable quality insights.

The ear is also a good location for monitoring signals from the brain and eyes, and is less obtrusive than brain-computer interfaces that must be worn on the head. Speech recognition is easily handled by a microphone on an earpiece, and head movement is easily tracked, too.

The challenge with a device that you wear in your ear is that it has to be small and light, which obviously restricts how many sensors you can pack in. The sensors have to be small and there has to be room for a battery to power them. For a consumer device, you need to fit in speakers and a microphone, too. It’s a design challenge to make something that is comfortable to wear, with a practical battery life and the features that provide value. However, since the pioneering work of the German startup Bragi, a lot of investment has gone into creating new technologies that are specifically designed to work at ultra-low power and in extremely constrained form factors. There is also historical work in the hearing aid space, and this level of advancement has meant that hearable technology is able to move at significant pace. With this backdrop, and due to the consumer pull and market validation of AirPods, new sensors and advanced technologies are finding their way into our ear-worn wearables. These factors somewhat mitigate the challenges we face in product development.

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Tudor Besleaga, Ph.D., and Jacob Skinner, D.Phil., Thrive Wearables, wrote in the current issue of meddeviceonline: “Cardiac monitoring is almost a standard feature of modern wearables but there are still opportunities to get better information and do more with the data. Seizing those opportunities could transform everything from medical care to athletic training and general well-being.

Cardiac monitoring has been around for over 100 years, but improved accuracy and wearable technology mean we can now get a better view of cardio performance not only in the hospital but also in the home, at work, or even while the wearer runs a marathon.

Turning this monitoring into actionable insights promises many benefits. Can we determine how well someone is recovering from surgery? Can we measure stress? And can we do so with a system that is low on user friction and high on user value? At present, the most accurate measurements come from the most cumbersome devices, and devices that are comfortable to wear tend not to offer the richest data.

The opportunity for the next generation of products and services is to further blur the distinctions between devices designed for medical professionals, performance athletes, and consumers. We have some obstacles to overcome before we get there, though.

Why Monitor More Than Heart Rate?

It’s worth starting by asking why we want to monitor heart signals with wearables in the first place. It is routine to monitor the heart dynamics of all kinds of patients. The cardiovascular system reveals how a patient is recovering from surgery, the effect of drugs, and more. Sudden changes can indicate serious problems.

Innovation in high-quality cardiac monitoring has also come from devices for athletes. For example, heart rate variability (HRV) –  the change in the time between heart beats – and resting heart rate are both indicators of overall fitness, so monitoring of these metrics first appeared in wearables for professional athletes and serious amateurs. These filtered down into more affordable consumer devices pitched as more general lifestyle and well-being assistants.

As well as cardiac monitoring for overall health, some devices can warn of sudden changes in heart rate intervals or test for atrial fibrillation (AFib), a common but potentially dangerous heart abnormality. In a sign of how serious diagnostic tools are being integrated into consumer products, the Apple Watch has been approved as a medical device by the FDA in the U.S. and by other regulators.

ECG Versus PPG

Different use cases will have different ideal technologies and form factors. Essentially, though, wearable cardiac monitors rely on two technologies with different approaches and distinct strengths and weaknesses.

The first is the electrocardiogram (ECG), first developed in the late 19th century. This measures the electrical signal produced by the heart as it beats and is a good guide to heart function. Measurement can be cumbersome, however. A hospital might use a 12-lead ECG, but this restricts movement and needs professional assistance. The consumerization of these devices sacrifices some data resolution but allows them to be worn unobtrusively and comfortably on the wrist for spot measurements instead of continuous ones. In recent years, some smartwatches have added ECG sensors, primarily for detecting things like AFib. These work by sending an electrical signal through the body so the user must wear the watch on one hand and touch the case with the opposite hand to complete the circuit.

Outside the hospital or a testing lab, a chest strap ECG is the best option. This isn’t as accurate as the multiple lead approach but almost everything in this space is a trade-off between user friction and perceived value. The value here is mobility, but the friction comes from reduced accuracy. Moreover, most people don’t want to wear a chest strap for long periods. There isn’t enough value. Cardiologists have tried to get patients to wear all kinds of devices and, other than implanted ones, devices on the wrist are about the only acceptable form factor for most patients.

That works well if the wearer can remember, or be reminded, to perform the ECG regularly but most people would prefer unobtrusive background monitoring. That can be done with a photoplethysmogram (PPG), which was invented in the 1930s and uses a light shone through the skin to track blood flow. This offers insights into cardiac hemodynamics, such as blood pressure trends and cardiac output but also provides localized measurements, such as tissue oxygenation. A downside of this type of sensing is its susceptibility to movement-induced signal loss, particularly at the wrist, where it’s most commonly worn. However, the wrist is a good location for user experience and PPG sensors are now standard in fitness bands and smartwatches, also making the sensor price point increasingly low.

PPG and ECG can complement each other in monitoring the cardiovascular system. The former can be adapted to various form factors and provides long-term continuous measurements, while the latter is limited to chest-based, albeit accurate, continuous measurements and wrist-based spot measurements. It is not uncommon to see PPG watches monitoring alongside chest straps during periods of intense exercise. Or PPG watches using ECG watch spot measurements to obtain quick but reliable and easily comparable readings.

Again, there is a trade-off. A PPG sensor might be most comfortable on the wrist, but the wrist isn’t the ideal place to monitor blood flow. We move our arms, especially when we exercise, which disrupts the signal and means lost data. The system must estimate, or do without, the missing information.

The Next Generation Of Cardio Sensors

Sensors, particularly PPG sensors, are improving all the time, so we can be optimistic about future devices. Most manufacturers have iteratively improved the designs of their PPG sensor modules regularly in recent years, indicating the likelihood of more application options as they improve further.

There are off-the-shelf integrated solutions for measuring PPG or ECG and exporting the data via a serial bus. However, these commonly fall short in signal quality compared to the best in class. Most developers design their own sensor systems, by combining a sensor-body interface, analog front end (AFE), and microcontroller unit (MCU).

The sensor-body interface, which is either an optical front end (OFE) for PPG or electrodes for ECG, is where the most value could be added. The OFE consists of one or more light emitters, commonly LEDs, one or more light sensors, commonly photodiodes (PDs), and a mask to control the light between them. The mask must ensure light passes through the tissue, rather than reflecting straight to the PD, that minimal ambient light enters the sensor, and that good pressure is maintained against the tissue.

The sensor-body interface must be optimized for where it will measure. Red or infrared light is fine for a fingertip PPG, for example, but green light makes data from the wrist less susceptible to motion noise. Some chest devices use both green and red to assess pulses at different depths; the higher the wavelength, the deeper it penetrates.

It is not uncommon for sensors to use discrete components assembled with the mask. However, integrated solutions can save space and cost. These provide PDs with peak sensitivity at the same wavelength as the LEDs and can output three channels (green, red, infrared). One downside is that the distance between the light emitter and the receiver is fixed and typically optimised for wrist cardiac measurement applications. That distance might need to be increased for measuring higher up the arm or at the chest in deeper tissue.

AFEs have improved a lot recently, particularly in signal preprocessing. They can measure ambient light and exclude the baseline, operate LEDs at very low duty cycles, increase energy efficiency, and filter specific frequencies. Some even calculate heart rate intervals for HRV. Many off-the-shelf integrated circuits (ICs) now provide collections of PPG, ECG, or both via multiple channels. When measuring ECG, it is important to select an IC that is optimized for dry electrodes, whether polymer conductive ones, as in chest straps, or stainless steel, as in many watches.

It is important to establish before development how much processing and analysis of the raw signal will be done on the device versus on servers. A lot of memory can be saved if only specific metrics are required, such as HRV, rather than complete raw data.

Since these signals are very susceptible to movement-induced noise, it is common to record accelerometer or inertial measurement unit (IMU) data along with the cardiac data. Motion data can help identify corrupted signal intervals and improve battery life by turning off recordings during high-intensity motion.

For ECG recordings, the MCU will be the main power consumer.  Integrated solutions (OFE, AFE, and MCU) do exist. However, they are not quite plug and play, as different form factors require optimization of sensor position and body interface. Furthermore, the onboard MCU means higher energy consumption. They also share limited processed data, as raw sensor data exposes these companies to intellectual property (IP) leak risks.

Medical device manufacturers could benefit from pursuing a hybrid agile approach when developing devices with cardiac sensors, as iterative sensor implementations are to be expected.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Risks and Opportunities of Innovative Technologies in Medical Applications

Dr. Abtin Rad, Global Director Functional Safety, Software and Digitization, TÜV SÜD Product Service GmbH wrote in the current issue of MedTechIntelligence: “An increasing number of medical devices incorporate artificial intelligence (AI) capabilities to support therapeutic and diagnostic applications. In spite of the risks connected with this innovative technology, the applicable regulatory framework does not specify any requirements for this class of medical devices. To make matters even more complicated for manufacturers, there are no standards, guidance documents or common specifications for medical devices on how to demonstrate conformity with the essential requirements.

Introduction

The term artificial intelligence (AI) describes the capability of algorithms to take over tasks and decisions by mimicking human intelligence.1 Many experts believe that machine learning, a subset of artificial intelligence, will play a significant role in the medtech sector.2,3 “Machine learning” is the term used to describe algorithms capable of learning directly from a large volume of “training data”. The algorithm builds a model based on training data and applies the experience, it has gained from the training to make predictions and decisions on new, unknown data. Artificial neural networks are a subset of machine learning methods, which have evolved from the idea of simulating the human brain.22 Neural networks are information-processing systems used for machine learning and comprise multiple layers of neurons. Between the input layer, which receives information, and the output layer, there are numerous hidden layers of neurons. In simple terms, neural networks comprise neurons – also known as nodes – which receive external information or information from other connected nodes, modify this information, and pass it on, either to the next neuron layer or to the output layer as the final result.5 Deep learning is a variation of artificial neural networks, which consist of multiple hidden neural network layers between the input and output layers. The inner layers are designed to extract higher-level features from the raw external data.

The role of artificial intelligence and machine learning in the health sector was already the topic of debate well before the coronavirus pandemic.6 As shown in an excerpt from PubMed several approaches for AI in medical devices have already been implemented in the past (see Figure 1). However, the number of publications on artificial intelligence and medical devices has grown exponentially since roughly 2005.

Figure 1. Selected PubMed publications for the search terms “artificial intelligence” and “medical technology” from 1950 to 2020.

Regulation of AI

Artificial intelligence in the medtech sector is at the beginning of a growth phase. However, expectations for this technology are already high, and consequently prospects for the digital future of the medical sector are auspicious. In the future, artificial intelligence may be able to support health professionals in critical tasks, controlling and automating complex processes. This will enable diagnosis, therapy and care to be optimally aligned to patients’ individual needs, thereby increasing treatment efficiency, which in turn will ensure an effective and affordable healthcare sector in the future.

However, some AI advocates tend to overlook some of the obstacles and risks encountered when artificial intelligence is implemented in clinical practice. This is particularly true for the upcoming regulation of this innovative technology. The risks of incorporating artificial intelligence in medical devices include faulty or manipulated training data, attacks on AI such as adversarial attacks, violation of privacy and lack of trust in technology. In spite of these technology-related risks, the applicable standards and regulatory frameworks do not include any specific requirements for the use of artificial intelligence in medical devices. After years of negotiations in the European Parliament, Regulation (EU) 2017/745 on medical devices and Regulation (EU) 2017/746 on in-vitro diagnostic medical devices entered into force on May 25, 2017. In contrast to Directives, EU Regulations enter directly into force in the EU Member States and do not have to be transferred into national law. The new regulations impose strict demands on medical device manufacturers and the Notified Bodies, which manufacturers must involve in the certification process of medical devices and in-vitro diagnostic medical devices (excluding class I medical devices and nonsterile class A in-vitro diagnostic medical devices, for which the manufacturer’s self-declaration will be sufficient).

Annex I to both the EU Regulation on medical devices (MDR) and the EU Regulation on in vitro diagnostic medical devices (IVDR) define general safety and performance requirements for medical devices and in-vitro diagnostics. However, these general requirements do not address the specific requirements related to artificial intelligence. To make matters even more complicated for manufacturers, there are no standards, guidance documents or common specifications on how to demonstrate conformity with the general requirements. To place a medical device on the European market, manufacturers must meet various criteria, including compliance with the essential requirements and completion of the appropriate conformity assessment procedure. By complying with the requirements, manufacturers ensure that their medical devices fulfill the high levels of safety and health protection required by the respective regulations.

To ensure the safety and performance of artificial intelligence in medical devices and in-vitro diagnostics, certain minimum requirements must be fulfilled. However, the above regulations define only general requirements for software. According to the general safety and performance requirements, software must be developed and manufactured in keeping with the state of the art. Factors to be taken into account include the software lifecycle process and risk management. Beyond the above, repeatability, reliability and performance in line with the intended use of the medical device must be ensured. This implicitly requires artificial intelligence to be repeatable, performant, reliable and predictable. However, this is only possible with a verified and validated model. Due to the absence of relevant regulatory requirements and standards, manufacturers and Notified Bodies are determining the “state of the art” for developing and testing artificial intelligence in medical devices, respectively. During the development, assessment and testing of AI, fundamental differences between artificial intelligence (particularly machine learning) and conventional software algorithms become apparent.

Credibility and trust in AI

Towards the end of 2019, and thus just weeks before the World Health Organization’s (WHO) warning of an epidemic in China, a Canadian company (BlueDot) specializing in AI-based monitoring of the spread of infectious diseases alerted its customers to the same risk. To achieve this the company’s AI combed through news reports and databases of animal and plant diseases. By accessing global flight ticketing data, the AI system correctly forecast the spread of the virus in the days after it emerged. This example shows the high level of performance that can already be achieved with artificial intelligence today.7 However, it also reveals one of the fundamental problems encountered with artificial intelligence: Despite the distribution of information of the outbreak to various health organizations in different countries, international responses were few. One reason for this lack of response to the AI-based warning is the lack of trust in technology that we do not understand, which plays a particularly significant role in medical applications.

In clinical applications, artificial intelligence is predominantly used for diagnostic purposes. Analysis of medical images is the area where the development of AI models is most advanced. Artificial intelligence is successfully used in radiology, oncology, ophthalmology, dermatology and other medical disciplines.2 The advantages of using artificial intelligence in medical applications include the speed of data analysis and the capability of identifying patterns invisible to the human eye.

Take the diagnosis of osteoarthritis, for example. Although medical imaging enables healthcare professionals to identify osteoarthritis, this is generally at a late stage after the disease has already caused some cartilage breakdown. Using an artificial-intelligence system, a research team led by Dr. Shinjini Kundu analyzed magnetic resonance tomography (MRT) images. The team was able to predict osteoarthritis three years before the first symptoms manifested themselves.8 However, the team members were unable to explain how the AI system arrived at its diagnosis. In other words, the system was not explainable. The question now is whether patients will undergo treatment such as surgery, based on a diagnosis made by an AI system, which no doctor can either explain or confirm.

Further investigations revealed that the AI system identified diffusion of water into cartilage. It detected a symptom invisible to the human eye and, even more important, a pattern that had previously been unknown to science. This example again underlines the importance of trust in the decision of artificial intelligence, particularly in the medtech sector. Justification of decisions is one of the cornerstones of a doctor-patient (or AI-patient) relationship based on mutual trust. However, to do so the AI system must be explainable, understandable and transparent. Patients, doctors and other users will only trust in AI systems if their decisions can be explained and understood.

Differences Compared to the Regulation of Conventional Algorithms

Many medical device manufacturers wonder why assessment and development of artificial intelligence must follow a different approach to that of conventional software. The reason is based on the principles of how artificial intelligence is developed and how it performs. Conventional software algorithms take an input variable X, process it using a defined algorithm and supply the result Y as the output variable (if X, then Y). The algorithm is programmed, and its correct function can be verified and validated. The requirements for software development, validation and verification are described in the two standards IEC 62304 and IEC 82304-1. However, there are fundamental differences between conventional software and artificial intelligence implementing a machine learning algorithm. Machine learning is based on using data to train a model without explicitly programming the data flow line by line. As described above, machine learning is trained using an automated appraisal of existing information (training data). Given this, both the development and conformity assessment of artificial intelligence necessitate different standards. The following sections provide a brief overview of the typical pitfalls.

Explainability of AI

A major disadvantage of artificial intelligence, in particular machine learning based on neural networks, is the complexity of the algorithms. This makes them highly non-transparent, hence their designation of “black-box AI” (see Figure 2). The complex nature of AI algorithms not only concerns their mathematical description but also—in the case of deep-learning algorithms—their high level of dimensionality and abstraction. For these classes of AI, the extent to which input information contributes to a specific decision is mostly impossible to determine. This is why AI is often referred to as “black box AI”. Can we trust the prediction of the AI system in such a case and, in a worst-case scenario, can we identify a failure of the system or a misdiagnosis?

Figure 2. Implementation of artificial intelligence (AI) as black box. Given the non-transparency of the artificial intelligence system, it is impossible to say whether the result is correct.

A world-famous example of the result of a “black-box AI” was the match between AlphaGo, the artificial intelligence system made by DeepMind (Google) and the Go world champion, Lee Sedol. In the match, which was watched by an audience of 60 million including experts, move 37 showed the significance of these particular artificial intelligence characteristics. The experts described the move as a “mistake”, predicting that AlphaGo would lose the match since in their opinion the move made no sense at all. In fact, they went even further and said, “It’s not a human move. I’ve never seen a human play this move”.

None of them understood the level of creativity behind AlphaGo’s move, which proved to be critical for winning the match. While understanding the decision made by the artificial intelligence system would certainly not change the outcome of the match, it still shows the significance of the explainability and transparency of artificial intelligence, particularly in the medical field. AlphaGo could also have been “wrong”!

One example of AI with an intended medical use was the application of artificial intelligence for determining a patient’s risk of pneumonia. This example shows the risk of black-box AI in the MedTech sector. The system in question surprisingly identified the high-risk patients as non-significant.10 Rich Caruana, one of the leading AI experts at Microsoft, who was also one of the developers of the system, advised against the use of the artificial intelligence he had developed: “I said no. I said we don’t understand what it does inside. I said I was afraid.”11

In this context, it is important to note that “open” or “explainable” artificial intelligence, also referred to as “white box”, is by no means inferior to black-box AI. While there have been no standard methods for “opening” the black box, there are promising approaches for ensuring the plausibility of the predictions made by AI models. Some approaches try to achieve explainability based on individual predictions on input data. Others, by contrast, try to limit the range of input pixels that impact the decisions of artificial intelligence.

Right to Explainability

Medical devices and their manufacturers must comply with further regulatory requirements in addition to the Medical Device Regulation (MDR) and the In-vitro Diagnostics Regulation (IVDR). The EU’s General Data Protection Regulation (GDPR), for instance, is of particular relevance for the explainability of artificial intelligence. It describes the rules that apply to the processing of personal data and is aimed at ensuring their protection. Article 110 of the Medical Device Regulation (MDR) explicitly requires measures to be taken to protect personal data, referencing the predecessor of the General Data Protection Regulation.

AI systems which influence decisions that might concern an individual person must comply with the requirements of Articles 13, 22 and 35 of the GDPR.

“Where personal data … are collected…, the controller shall… provide….the following information: the existence of automated decision-making … and… at least in those cases, meaningful information of the logic involved…”

In simple terms this means, that patients who are affected by automated decision-making must be able to understand this decision and have the possibility to take legal action against it. However, this is precisely the type of understanding which is not possible in the case of black box AI. Is a medical product implemented as black-box AI eligible for certification as a medical device? The exact interpretation of the requirements specified in the General Data Protection Regulation is currently the subject of legal debate.

Verification and Validation of the AI model

The Medical Device Regulation places manufacturers under the obligation to ensure the safety of medical devices. Among other specifications, Annex I to the regulation includes, , requirements concerning the repeatability, reliability and performance of medical devices (both for stand-alone software and software embedded into a medical device):

“Devices that incorporate electronic programmable systems, including software, … shall be designed to ensure repeatability, reliability and performance in line with their intended use.“ (MDR Annex I, 17.1)15

Compliance with general safety and performance requirements can be demonstrated by utilizing harmonized standards. Adherence to a harmonized standard leads to the assumption of conformity, whereby the requirements of the regulation are deemed to be fulfilled. Manufacturers can thus validate artificial intelligence models in accordance with the ISO 13485:2016 standard, which, among other requirements, describes the processes for the validation of design and development in clause 7.3.7.

For machine learning two independent sets of data must be considered. In the first step, one set of data is needed to train the AI model. Subsequently, another set of data is necessary to validate the model. Validation of the model should use independent data and can also be performed by cross-validation in the meaning of the combined use of both data sets. However, it must be noted that AI models can only be validated using an independent data set. Now, which ratio is recommended for the two sets of data? This is not an easy question to answer without more detailed information about the characteristics of the AI model. A look at the published literature (state of the art) recommends a ratio of approx. 80% training data to approx. 20% validation data. However, the ratio being used depends on many factors and is not set in stone. The notified bodies will continue to monitor the state of the art in this area and, within the scope of conformity assessment, also request the reasons underlying the ratio used.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Alan Grau, VP of IoT/Embedded Solutions at Sectigo, wrote in MedTechIntelligence: “Medical device manufacturers continue to develop new, highly sophisticated and increasingly connected products. These products offer a wide range of benefits: Improved treatments, more precise diagnostics, better patient monitoring, automated control, and central reporting and monitoring of data.

This increased connectivity, however, comes with risks for both patients and providers.

Even though these companies are heavily investing in the development of new medical device technologies, they often lack the security expertise and resources to ensure high levels of security are built into these products. Many devices employ new protocols, platforms and middleware solutions that have not been thoroughly vetted for security issues. The result, not surprisingly, is a slew of devices that are easily compromised by hackers.

We continue to see headlines of new security vulnerabilities found in critical medical devices. Ransomware attacks have targeted hospitals and medical providers with alarming success. In these kinds of attacks, hackers compromise a system, encrypting critical data so the systems cannot operate, then require a ransom payment to restore the system to working order.

Past ransomware attacks have targeted IT and database systems, but future attacks may focus on medical devices. In fact, in 2019, cybersecurity experts found dangerous vulnerabilities in the technical design of some insulin pumps, prompting the FDA to issue a warning that hackers could compromise insulin pumps by connecting to them via WiFi and changing the pump’s settings to either under- or over-deliver insulin. If hackers are able to control systems that impact patient outcomes, they will have tremendous leverage for their ransom demands.

Use of multiple layers of protection, including firewalls, authentication, security protocols and intrusion detection/intrusion prevention, is a long-established driving principle for enterprise security. In contrast, most medical devices lack basic firewalls or security protocols, and often rely on little more than simple password authentication. There was an assumption that these devices are not attractive targets to hackers, or are not vulnerable to attacks, but that is no longer valid. Attacks against all types of embedded devices, including medical products, are on the rise, and greater security measures are now needed.

For more than 25 years, cybersecurity has been a critical focus for large enterprises. Now medical device design engineers need to take a page from the enterprise security playbook.

Embedded Security Challenges

Medical devices are very different from standard PCs. They are fixed-function devices designed to perform a specialized task. Installing new software on the system in the field often requires a specialized upgrade process or is simply not supported. These devices are optimized to minimize processing cycles and memory usage, so they lack extra processing resources. PC security solutions won’t solve the security challenges of these devices.

Challenges for medical device security include:

1. Critical functionality: Medical devices control life-enabling systems and manage sensitive data.
2. Replication: Once designed and built, medical devices are mass produced, resulting in thousands to millions of identical devices. Once discovered, a successful attack against one of these devices can be replicated across all the devices.
3. Security assumptions: Many medical device engineers have long assumed that their products are not targets for hackers and have not considered security a critical priority.
4. Patching limitations: Most medical devices are not easily upgraded. Once they are deployed, they will only run the software that was originally installed at the factory.
5. Long lifecycle: The lifecycle for medical devices may be as long as 10, 15 or even 20 years. Building a device that will stand up to the security requirements of the next two decades is a tremendous challenge.
6. Deployed outside of the enterprise security perimeter: Medical devices may be mobile or may be deployed in the home, environments lacking the protections found in a corporate environment.
7. Siloed: No way for the end user to easily monitor the device’s security health or make changes.

Cyberattacks and The Motivated Hacker

The level of security required for a medical device varies depending upon the function of the device. Rather than asking if the device is secure, OEMs should be asking if the device is secure enough. A robotic surgical system clearly needs a very different level of security than sensors equipped with communication capability for remote monitoring of patients.
Hacking is not just the domain of bored teenagers, hacking drones, or even the small groups of motivated hackers. When the stakes are high enough, cyberattacks are typically multi-phased, multi-year efforts that are carried out by large, well-funded teams of hackers.

We are no longer talking about protecting a device from just malformed IP packets or DoS packet floods. Hackers often have detailed information about the device they are targeting and have sophisticated toolkits and skills that can be used to develop attacks.

Have you considered how to protect devices from attack by a group with detailed knowledge of the inner workings of your product?

FDA Cybersecurity Guidelines

The FDA has issued guidance for OEMs building medical devices. A few of the capabilities recommended in the FDA guidelines include:

• Restricting unauthorized access to medical devices
• Making certain that firewalls are up-to-date
• Monitoring network activity for unauthorized use
• Disabling all unnecessary ports and services

As an engineer working on a medical device, what do these guidelines mean? Many medical devices are specialized products and the security solutions used for standard PCs often won’t work for specialized devices. Clearly, meeting the security guidelines is important. Doing so requires an approach that is customized to the needs of the device.

Security Requirements for Medical Devices

A security solution for medical devices must protect firmware from tampering, secure the data stored by the device, secure communication, and protect the device from cyberattacks. This can only be achieved by building in security from the early stages of design.

There is no “one-size-fits-all security solution” for medical devices. Engineers must take into consideration the cost of a security failure (economic, environmental, social, etc.), the risk of attack, available attack vectors, and the cost of implementing a security solution. Table I outlines the features that need to be considered.

Table I. Security features that should be considered in embedded medical devices.

Integrating Security into The Device

Building protection into the device itself provides a critical security layer that ensures devices are no longer depending on the corporate firewall as their sole layer of security and allows security to be customized to the needs of the device. The engineering team must be as focused on security as they are on the new capabilities of the device. Building security capabilities into a medical device will enable the device to meet the FDA security guidelines.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

FDA gives an update on the Software Precertification Pilot Program:

“What Is the Software Pre-Cert Pilot Program?

The Software Precertification (Pre-Cert) Pilot Program, as outlined in the FDA’s Digital Health Innovation Action Plan [PDF], will help inform the development of a future regulatory model that will provide more streamlined and efficient regulatory oversight of software-based medical devices developed by manufacturers who have demonstrated a robust culture of quality and organizational excellence, and who are committed to monitoring real-world performance of their products once they reach the U.S. market.

This proposed approach aims to look first at the software developer or digital health technology developer, rather than primarily at the product, which is what we currently do for traditional medical devices. Because software products can be adapted to respond to glitches, adverse events, and other safety concerns quickly, the FDA is working to establish a regulatory framework that is equally responsive when issues arise to help ensure consumers continue to have access to safe and effective products. In the Pre-Cert program, the FDA is proposing that software products from precertified companies would continue to meet the same safety and effectiveness standard that the agency expects for products that have followed the traditional path to market.

This pilot is an important first step to help us explore and evaluate the program model to inform how we establish the Pre-Cert Program. Pre-Cert 1.0, the first version of the program that was available for pilot testing within the FDA’s current authorities in 2019, is limited to manufacturers of software as a medical device (SaMD). Learn more about software as a medical device (SaMD)External Link Disclaimer.

As the FDA leverages insights from testing of Pre-Cert 1.0, we may find that the voluntary program could include software in a medical device (SiMD) or other software that could be considered accessories to hardware medical devices.

How Does the Pre-Cert Pilot Program Work?

The Software Precertification Pilot Program version 1.0 Working Model (PDF) explains how the FDA has reimagined its way of regulating digital health products and details the proposed key components of the Pre-Cert pilot program.

In 2019, the Software Pre-Cert program entered its test phase and the FDA shared the Test Plan (PDF).

The FDA’s Test Plan is designed to assess whether the Excellence Appraisal and Streamlined Review components together produce an equivalent basis for determining reasonable assurance of safety and effectiveness for a software device prior to its introduction to the market, as compared to the FDA’s traditional models.

The FDA describes how it plans to implement the Pre-Cert Pilot Program within its current authorities in the Regulatory Framework. Learn more about the Regulatory Framework for the Pre-Cert model.

In addition, the 2020 Update summarizes the FDA’s test activities, provides an update on our progress, shares what we have learned, and outlines next steps. For more information, see Developing the Software Precertification Program: Summary of Learnings and Ongoing Activities: 2020 Update [PDF – 1.5 MB].

Proposed Key Components of a Future Pre-Cert Program:

The FDA’s Total Product Lifecycle (TPLC) approach enables the evaluation and monitoring of a software product from its premarket development to postmarket performance, along with continued demonstration of the organization’s excellence. Learn more about this approach in the version 1.0 working model (PDF).

• Excellence Appraisal: Identifying the objective criteria and methodology that the FDA will use to pre-certify a company and decide whether a company can keep its precertification status.
  
  The FDA is currently basing the Pilot Program’s criteria on five excellence principles: patient safety, product quality, clinical responsibility, cybersecurity responsibility, and proactive culture. The FDA is currently considering two levels of precertification based on how a company meets the excellence principles and whether it has demonstrated a track record in delivering safe and effective software products.
• Review Determination: Developing a risk-based framework so a precertified company can determine the premarket review pathway for their products. Potentially precertified companies could market their lower-risk devices without the FDA’s premarket review or only a streamlined premarket review based on the company’s precertification level and International Medical Device Regulators Forum (IMDRF) risk categorization.
  
  The FDA is planning to leverage the IMDRF framework, to the extent consistent with current statutory authority, to help determine the risk categorization of a SaMD product, incorporating information about the medical purpose of the SaMD and the seriousness of the medical condition that the SaMD is intended to treat.
  
  The FDA is also considering appropriate means to educate patients and providers about the premarket review and postmarket monitoring obligations for each SaMD risk category.
• Streamlined Review: Identifying the type of information that a precertified company would include in its premarket submission for the FDA to review software products for safety and effectiveness before patients access them.
  
  The FDA is exploring using an interactive streamlined review of a SaMD with information the agency already has gained from the process to precertify a company, and additional information the company would share about the SaMD’s product performance, clinical association between the SaMD output and a clinical condition, and safety measures.
• Real-world Performance: Identifying the type of information that may be available to or accessibly by a precertified company about how its software product is performing with patients to support the regulatory status of the product and new and evolving product functions.
  
  The FDA is considering how best to work with a company to collect and interpret real-world information about a SaMD and to evolve the product’s safety and effectiveness to address any emerging risks. The sources of real world performance data may include information about a user’s experience, software performance data, and clinical outcomes.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

The FDA has launched its Digital Health Center of Excellence (DHCoE), as the agency continues with its commitment to advancing use of technology such as mobile health devices, software and wearables to create medical products.

The FDA  announced: “The launch of the Digital Health Center of Excellence is an important step in furthering the agency’s overarching dedication to the advancement of digital health technology, including mobile health devices, Software as a Medical Device (SaMD), wearables when used as a medical device, and technologies used to study medical products.

“Establishing the Digital Health Center of Excellence is part of the FDA’s work to ensure that the most cutting-edge digital health technologies are rapidly developed and reviewed in the U.S.,” said FDA Commissioner Stephen M. Hahn, M.D. “Today’s announcement marks the next stage in applying a comprehensive approach to digital health technology to realize its full potential to empower consumers to make better-informed decisions about their own health and provide new options for facilitating prevention, early diagnosis of life-threatening diseases, and management of chronic conditions outside of traditional care settings. The Digital Health Center of Excellence will provide centralized expertise and serve as a resource for digital health technologies and policy for digital health innovators, the public, and FDA staff.”

The FDA will continue to build and formalize the coordinating structure and operation of the Digital Health Center of Excellence as part of an effort to modernize digital health policies and regulatory approaches, and provide efficient access to highly specialized expertise, knowledge, and tools to accelerate access to safe and effective digital health technology. The agency is appointing Bakul Patel as the first director. Bakul Patel has been leading regulatory and scientific efforts related to digital health devices at the FDA since 2010.

“The establishment of the Digital Health Center of Excellence is part of the planned evolution of the FDA’s digital health program to amplify the digital health work that is already being done and building upon years of work at the agency,” said Jeff Shuren, M.D., J.D., director of CDRH. “In the last several years, we have established partnerships internally and externally to coordinate digital health activities and to promote the consistency of regulatory policy while continuing to innovate in our regulatory approaches.”

Please find the complete article  here.

For further information please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Bart Degroote, Senior Project Manager at pi life sciences consultancy, commented the FDA draft guidance on Computer Software Assurance within the PI knowledge page:

“The FDA draft guidance on Computer Software Assurance is a paradigm shift from document focused computer system validation to critical thinking assurance practices. The Guidance is on FDA’s list for release in September 2020 and applies to non-product quality system software solutions. The principles and approaches will apply to all regulated organizations.

How it all started

The concept of validation was derived from engineering validation principles that have been extended to the software industry. Feeling the necessity to validate computer systems, the FDA published the ‘bluebook’ (1983) this was a guide to the inspection of computerized systems in pharmaceutical processing.

These regulations on the use of electronic records and electronic signatures are formalized in 1997 in 21 CFR part 11 the FDA and revised in 2003, for Eudralex (EU GMP regulations) this is Annex 11 (EME 1998).

According to both computer system validation is defined as: “Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled”

Purpose and initial need for CSV

The purpose of the validation process is to provide a high degree of assurance that a computer system will consistently produce electronic records which meets predetermined specifications and quality attributes.

FDA regulations mandate the need to perform Computer System Validation and these regulations have the impact of the law. Having the evidence that computer systems are serving their intended purpose and operating properly represents a good business practice.

Failure to take corrective action immediately can result in shutting down manufacturing facilities, consent decrees, and stiff financial penalties.

Why we need a new approach

The Guidance on computer system validation is already dating back to 2003 in a rapidly changing digital landscape and is no longer aligned with new technologies. This makes it unclear on how much testing is enough and where to focus that testing.

FDA believes the use of automation, information technology and data solutions throughout the life cycle can provide significant benefits to enhance quality and patient safety. This substantial benefit in enhancing quality is shown in other industries utilizing thorough automation.

At this moment CSV is an obstacle in the process to move to a more automated environment, this due to the required extensive testing and comprehensive documentation that demonstrate the validation of computer software.

To support the use of this new technologies FDA is drafting new guidelines “Computer Software Assurance for Manufacturing, Operations, and Quality System Software”, CSA will tackle the issues we have at this moment with CSV.

Additionally, FDA intends to focus on direct impact systems and not on the indirect systems (support tools).

The paradigm shift of CSA

The new paradigm will focus on critical thinking (risk-based), assurance needs, testing activities and documentation in that order.

Risk determination should focus on:

• Does the software impact patient safety?
• Does this software impact product quality?
• How does this software impact your quality system integrity?

Comparison CSV VS CSA

Focus on creating documentary records for compliance VS Focus on testing for higher confidence in system performance

Validating everything with the risk to miss higher risk functionality VS Risk-based assurance, applying the right level of risk to patient safety and/or product quality

Ignoring previous assurance activity or related risk controls VS Taking prior assurance activities into account and upstream / downstream risk controls”

Please find the complete article  here.

Please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

BCG recently published a fascinating insight into one of latest software industry best practices:

DevOps Takes Agile Further—and Across the Software Life Cycle

Thriving in the digital age requires levels of efficiency, agility, and quality in software development that can be delivered only by fully embracing DevOps practices, which combine development and operations in IT.

Agile methodologies have afforded many companies a much-needed tool in the digital era: a collaborative and flexible way to develop software. Cross-functional teams, quick and frequent iterations, and continual testing and feedback are powerful agile practices that have enabled companies to improve their development process. But businesses can realize even greater transformative change—and greater success—by implementing a second set of practices known as DevOps.

What Is DevOps?

DevOps combines the development and operations activities of an IT organization to increase collaboration and automation along the entire product lifecycle.

Specifically, the approach breaks down the walls within IT to embed employees from IT operations onto cross-functional agile teams working on software development. New processes and tools are used to align the IT and software development work.

This set of practices is not an alternative to agile but a complement. A DevOps approach takes agile a step further and applies it beyond the plan, design, build, and test stages of software development to the rest of the software lifecycle: deployment, release, operation, and monitoring.

The efficiency and speed gains that DevOps can deliver are particularly critical in today’s environment, when customers as well as technological developments are demanding ever-shorter development cycles and ever-increasing quality.

The Elements and Application of DevOps

In combination with agile, DevOps delivers six key elements that serve as the building blocks of a holistic transformation of software development. …”

Please find the complete article  here.

Please get in touch with us for further support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Kathleen Warner, Ph.D., RCM Technologies, reports in the recent issue of meddeviceonline.com about FDA`s transition from Computer System Validation to Computer Software Assurance:

“The FDA regulation 21 CFR Part 11 in 1997 and the related guidance of 2003 paved the road to implementation of computer system validation (CSV) by life sciences companies.

As pharmaceutical companies perfected their business processes and became more efficient in validating computer systems, the piles of documentation continued to grow without significant quality benefits. The focus was on speed, documentation accuracy and completeness, inspections, audits, and complying with the regulation.

In 2011 the Center for Devices and Radiological Health (CDRH) initiated the Case for Quality, a new program that identified barriers in the current validation of software in medical devices guidance (released in 2002). Now, CDRH — in cooperation with the Center for Biologics Evaluation and Research (CBER) and the Center for Drug Evaluation and Research (CDER) — is preparing to release new guidance, Computer Software Assurance for Manufacturing, Operations and Quality Systems Software, in late 2020.

This new guidance will provide guidelines for streamlining documentation with an emphasis on critical thinking, risk management, patient and product safety, data integrity, and quality assurance. Even though this guidance is being developed for the medical device industry, the FDA has indicated it should be considered when deploying non-product, manufacturing, operations, and quality system software solutions such as quality management systems (QMS), enterprise resource planning (ERP) systems, laboratory information management systems (LIMS), learning management systems (LMS), and electronic document management systems (eDMS). As such, the guidance will be applicable to research and development (R&D), clinical, laboratory, and other groups within pharmaceutical, biopharmaceutical, and medical device companies that are currently meeting the regulations for electronic records and electronic signatures (ERES)¹ and computer system validation (CSV).²

As the digital world evolves, new technologies, including automation and artificial intelligence (AI), are hitting the marketplace and focusing on quality through unscripted and automated testing and smart applications. This paper describes how computer system validation (CSV) is performed today, introduces the concept of computer software assurance (CSA), and discusses how CSA can refocus validation on what’s important in the new world of digital technologies.

Computer System Validation is the process of achieving and maintaining compliance with the relevant GxP regulations defined by the predicate rule.³ Fitness for intended use is achieved by adopting principles, approaches, and life cycle activities. The validation methodology determines the framework to follow in developing the validation plans and reports and applying appropriate operational controls throughout the life cycle of the system. 

CSV is typically performed following the standard operating procedures (SOPs) for the software development life cycle (SDLC) and the CSV, respectively.  According to GAMP 5, the computerized system validation methodology comprises four distinct life cycle phases:  Concept, Project, Operation, and Retirement.

1. Concept Phase: During this phase, activities are initiated to justify project commencement.
2. Project Phase: During this phase, the overall system is implemented and tested according to preapproved documents. The SDLC includes, but is not limited, to the following: validation methodology and plan, requirements, software documentation and test plans, traceability matrix, and summary reports.
3. Operation Phase. During this phase, routine, day-to-day activities associated with the system (as defined in user manuals, SOPs, work instructions, etc.) are performed and include, but are not limited to, the following: backup and restore, disaster recovery, change management, incident/deviation management, access and security management, and periodic review.
4. Retirement Phase. During this phase, the system is no longer used, needed, or operational and is at the end of its life cycle. A retirement/decommissioning plan is developed to document the approach and tasks to manage the data and records.”

Please find the complete article  here.

Please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

MD101 comments in their recent blog the new guidance on cybersecurity for medical devices: the MDCG 2019-16: “This guidance covers a broad range of topics applicable to all stakeholders in the medical device supply chains, and to end-users. It explains a bit why it is 46 pages long.

Section 1 – Introduction

The first section of the guidance draws the link between regulatory requirements and cybersecurity processes / artifacts. The figures 1 & 2 are quite a good synthesis of the MDR requirements covering cybersecurity. Note that these figures could be duplicated with several other topics, like electrical security, biocompatibility (and so on), and state-of-the-art applicable standards.

The topics listed in section 1.4 cover all topics where cybersecurity is involved. This list is very useful to assess where cybersecurity requirements shall be implemented in your QMS processes. E.g: design controls, post-market surveillance.

Section 2 – Basic cyber concepts

If you’ve already read documents like AAMI TIR 57 or the 2 FDA guidances on cybersecurity, you will retrieve in this section some information common to these documents. The novelty in this MDCG guidance is the link between these concepts and the MDR General Safety and Performance Requirements (GSPR).

We also retrieve in this section concepts of defense in depth, good security hygiene (basic security hygiene in FDA guidance), and the relationship between security risks and safety risks.

Another concept is introduced, not so easily found in other guidance: the link between usability engineering and cybersecurity:

[a vulnerability] should be regarded as an enabler of reasonably foreseeable misuse .

If an exploit exists, an user will use it with a probability to assess, linked to the user’s education level and the ease of exploitation based on use scenarios.

The concept of joint responsibility is also introduced. All stakeholders in the supply chain shall take their part of the job: medical device integrators operators, and users. Manufacturers, don’t be fooled by this joint responsibility: as usual, your responsibility will be engaged in case of adverse event. You shall have established processes to ensure the proper installation, deployment, configuration, and exploitation of your devices in a secure manner. Simply said, this joint responsibility doesn’t exonerate manufacturers. Quite the opposite, it engages the responsibility of other stakeholders.

Section 3 – Secure design and manufacture

Section 3 delves into technical details (as far as a guidance can do, it’s not a standard), with a list of good practices to ensure that the device is secure by design. These 6 best practices can be seen as the steps of processes found in IEC 62304 design and maintenance processes:

    Security management:

        4.1 of ISO 13485, for the security risk management process

        5.1 of IEC 62304: Software development plan

        6.1 of IEC 62304: Software maintenance

    Specification of Security Requirements:

        5.2 of IEC 62304: software requirements analysis

    Secure by design, including defense in depth:

        5.3 of IEC 62304: software architecture

    Secure implementation:

        5.4 of IEC 62304: software detailed design

        5.5 of IEC 62304: software implementation and unit verification

        and a precision on SOUP management

    Secure Verification and Validation

        5.6 of IEC 62304: software integration testing

        5.7 of IEC 62304: software system verification

    Management of security-related issues

        6.2 of IEC 62304: Problem and modification analysis

        9 of IEC 62304: Problem resolution

    Security update management

        6.3 of IEC 62304: Modification implementation

        8.2 of IEC 62304: Change control

    Security guidelines:

        5.8 Software release

        and also software documentation, see IEC 82304-1 section 7.

Security Risk management

Section 3.2 continues with recommendations on the security risk management process, especially the link between security risks and their impact on safety. A very important remark is present in this section, for the sake of clarity of safety risk management reports: safety risk assessment might list generic security related hazards (…). This is to avoid detailing every possible attack vector.

This section also insists on the fact that compliance to GSPR 1 to 4 requires to assess security risks. Thus, cybersecurity isn’t nested only in GSPR 17.2 on software, but is promoted to the first main GSPR’s.

Security capabilities

Section 3.3 lists some possible security capabilities for software. This list is absolutely not exhaustive. This is a good starting point, though.

Interestingly, this section also contains an analogy between the precedence of safety mitigation actions (section 6.2 of ISO 14971) and their security risk equivalent. Worth reading!

This section ends with a remark on the need to maintain safety and effectiveness but also performance requirements and efficiency of mitigation actions, with security capabilities. New columns to your risk assessment matrices?”

Please find the complete article  here.

Please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Ben Hartwig, Web Operations Executive, InfoTracer gives in a recent article of the Medical Product Outsourcing Magazine (MPO) an overview about the “2020 MedTech Cyberchaos”.

The issue with medical technology is the cybersecurity isn’t up to the level of where it needs to be, and criminals know this. Manufacturers that build these products have a treasure trove of sensitive information on vendors and clients alike. If medical device makers don’t perform their due diligence by conducting a criminal records search on new employees, one bad actor on the inside can steal all their valuable data or give network access to hackers from the outside.

Weak Links in the Medtech Manufacturing Industry

While some medical manufacturers are shoring up their cybersecurity response, others aren’t, and they may be exposing their weak IT infrastructure to cyberattacks. Following are the most vulnerable network points that need immediate attention.

Compromised Cloud Infrastructure

Plenty of medical manufacturers are leveraging the power of the cloud to advance healthcare technology because sharing information with speed and efficiency can save lives. However, the lack of cloud computing professionals working in these companies or the current staff’s lack of knowledge in port data security and legacy systems can lead to holes in the cloud architecture that cybercriminals can exploit. Regular scanning can detect these vulnerabilities, but not all manufacturers are up to the task.

 Open-Source Software

While using open-source software isn’t inherently wrong, developers need to devote their time and effort to make proprietary changes to the code that improves security and locks it down so no one outside the organization can penetrate it. By definition, open-source software means everyone has the same access to the lines of code that make it up. If a lazy developer uses the code “as is” or installs an untested program from an unsecured hard drive, hackers can easily bypass and infiltrate the system.

 Poor Internal Security Protocols

Some manufacturers don’t have stringent internal security policies in place to secure the premises from rogue employees and protect their sensitive data. As harsh as it sounds, the weakest link in any organization will always be the employees. This is why the vetting process before hiring should include criminal records search and other checks to ensure the person is legit even before he or she steps inside the building. There should be a culture of data protection instilled in everyone, so no one can make the common mistake of using unsecured freeware, using unsecured WiFi, or responding to phishing attempts. Employees should be informed about tools such as email lookup, and username search that can help them to be protected from common scams.

Please find the complete article  here.

Please get in touch with us:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

healthcare-in-europe.com comments on Johan Sjöberg, a medical physicist at Karolinska University Hospital in Stockholm, Sweden, who claims that cloud computing in healthcare is a couple of decades behind the rest of society.

“The purpose of a well-functioning healthcare system is to provide excellent care to its patients at the lowest cost possible. This is what value-based healthcare is all about,” says Sjöberg. Unfortunately, many healthcare providers aren’t entirely there yet. “What is a cloud? It’s just somebody else’s computer, right? There’s nothing magical about it,” Johan Sjöberg suggests. “But there are a lot of benefits that are attributed to the concept of a cloud service. “You have a central repository. It’s simple to build interfaces between the different layers in the databases. That offers the opportunity to roam the data and actually pull some interesting information from those databases, which is valuable to our patients. It’s a shared platform. It offers a lot of opportunities, not just for data management, but also for communication management.”

Sjöberg notes that the amount of data generated in healthcare today is “quadrupling every second year”, yet the challenge lies in figuring out if there’s anything interesting in that health data.

What the cloud environment does is break down the silo walls and enables a more holistic view on patient care, according to Thomas Friese, Head of Digital Platform for Siemens Healthineers. He notes that many leading-edge cloud solutions are forward looking in terms of the applications and benefits they can offer a healthcare enterprise. “The cloud offers a good opportunity to easily add on or migrate to new applications; it enables you to easily evolve.”

Continuously improving care

Cloud computing allows healthcare enterprises to utilize the latest technology at a fraction of the cost and deployment time of a local installation. For example, providers of cloud-based AI applications are highly scalable and can use a practically unlimited number of Graphical Processing Units (GPUs). A cloud environment seamlessly unites healthcare professionals in a large-scale team effort, making the knowledge and insights of individual professionals available across a global network. Big data becomes readily available, accessible, and easy to analyze as data sets located anywhere in the world are available to improve diagnostic capabilities, provide integrated decision support, and help physicians get a comprehensive view of a patient’s condition. Individualized treatment plans can increasingly be developed from valuable quantitative data. Enterprise-wide artificial intelligence-based assistants can serve as a clinical decision support mechanism (CDSM) for referring physicians ordering imaging tests.

Please find the complete article  here.

Please get in touch with us for any further support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

On March 26, 2020, the FDA published a paper called “Digital Health Innovation Action Plan” outlining the efforts to reimagine the FDA’s approach to ensuring all Americans have timely access to high-quality, safe, and effective digital health products. As part of this plan, the FDA committed to several key goals:

• Issuing guidance to modernize their policies.
• Increasing the number and expertise of digital health staff at the FDA.
• Developing the Digital Health Software Precertification Pilot Program (“Pre-Cert”).

From mobile medical apps and software that support the clinical decisions doctors make every day to artificial intelligence and machine learning, digital technology has been driving a revolution in health care. Digital health tools have the vast potential to improve our ability to accurately diagnose and treat disease and to enhance the delivery of health care for the individual. Digital tools are giving providers a more holistic view of patient health through access to data and giving patients more control over their health. Digital health offers real opportunities to improve medical outcomes and enhance efficiency.

How Is the FDA Advancing Digital Health?

The FDA’s Center for Devices and Radiological Health (CDRH) has established the Digital Health program, which seeks to better protect and promote public health and provide continued regulatory clarity by:

• Fostering collaborations and enhancing outreach to digital health customers, and
• Developing and implementing regulatory strategies and policies for digital health technologies.

How Are Digital Health Products Used?

Providers and other stakeholders are using digital health technologies in their efforts to:

• Reduce inefficiencies,
• Improve access,
• Reduce costs,
• Increase quality, and,
• Make medicine more personalized for patients.

Patients and consumers can use digital health technologies to better manage and track their health and wellness related activities.

The use of technologies, such as smart phones, social networks, and internet applications, is not only changing the way we communicate, but also providing innovative ways for us to monitor our health and well-being and giving us greater access to information. Together, these advancements are leading to a convergence of people, information, technology, and connectivity to improve health care and health outcomes.

Why Is the FDA Focusing on Digital Health?

Many medical devices now have the ability to connect to and communicate with other devices or systems. Devices that are already FDA approved, authorized, or cleared are being updated to add digital features. New types of devices that already have these capabilities are being explored.

Many stakeholders are involved in digital health activities, including patients, health care practitioners, researchers, traditional medical device industry firms, and firms new to the FDA regulatory requirements, such as mobile application developers.

The following are topics in the digital health field on which the FDA has been working to provide clarity using practical approaches that balance benefits and risks:

• Artificial Intelligence and Machine Learning (AI/ML) in Software as a Medical Device
• Cybersecurity
• Device Software Functions, including Mobile Medical Applications
• Health IT
• Medical Device Data Systems
• Medical Device Interoperability
• Software as a Medical Device (SaMD)
• Telemedicine
• Wireless Medical Devices

Please find the complete FDA article  here.

Please get in touch with us for any further support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Medtechdive.com reports that the European Commission’s Medical Device Coordination Group (MDCG)  is allowing notified bodies to perform remote audits during the coronavirus outbreak, according to a ​guidance posted Wednesday. The MDCG detailed how notified bodies can run audits while quarantine orders and travel restrictions are stopping them from conducting site visits. The pandemic-oriented guidance the day after the Council of the European Union responded to the Commission’s proposed delay of the Medical Device Regulation. The Council’s planned amendments to the proposal clear up the confusion over whether the delay applies to all aspects of MDR.

Travel restrictions across the EU are stopping notified bodies from performing the on-site assessments central to their work. Recognizing that threat to the supply of medical devices, MDCG, an advisory group consisting of member state officials and industry players, laid out temporary measures notified bodies can take to work around the restrictions.

In some circumstances, notified bodies may perform remote audits. That option is open to notified bodies that have to carry out surveillance and recertification audits under the device directives, as well as when a manufacturer has filed a change notification or switched to a different notified body.

MDCG developed the guidance primarily to help notified bodies designated under the outgoing device directives. However, the advisory group said the flexibility provided in the guidance may apply to MDR and IVDR “in the event that the availability of devices is affected by COVID-19 restrictions.”

If an audit falls within the scope of the guidance, a notified body can leverage technology to perform a remote assessment. The guidance permits the off-site assessment of documents and records, and use of results from audits run under the Medical Device Single Audit Program, an initiative involving FDA and other regulators outside of the EU.

MDCG expects notified bodies to assess how to make use of the flexibilities provided by the guidance on a case-by-case basis. In doing so, notified bodies should consider the risks of each case, for example by factoring in their experience of the manufacturer and its compliance record.

The group is still developing guidance on the operational implementation of the principles​.

Details of the flexibilities available to notified bodies emerged a day after the Council advanced the planned delay of the MDR date of application.

Please find the complete FDA article  here.

Please get in touch with us for any further SaMD support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

On April 2, 2019, the FDA published a discussion paper “Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) – Discussion Paper and Request for Feedback” that describes the FDA’s foundation for a potential approach to premarket review for artificial intelligence and machine learning-driven software modifications.

FDA proposed Regulatory Framework for Al/ML Software

Artificial intelligence and machine learning technologies have the potential to transform health care by deriving new and important insights from the vast amount of data generated during the delivery of health care every day. Medical device manufacturers are using these technologies to innovate their products to better assist health care providers and improve patient care. The FDA is considering a total product lifecycle-based regulatory framework for these technologies that would allow for modifications to be made from real-world learning and adaptation, while still ensuring that the safety and effectiveness of the software as a medical device is maintained.

What is Artificial Intelligence and Machine Learning?

Artificial Intelligence has been broadly defined as the science and engineering of making intelligent machines, especially intelligent computer programs (McCarthy, 2007). Artificial intelligence can use different techniques, including models based on statistical analysis of data, expert systems that primarily rely on if-then statements, and machine learning.

Machine Learning is an artificial intelligence technique that can be used to design and train software algorithms to learn from and act on data. Software developers can use machine learning to create an algorithm that is ‘locked’ so that its function does not change, or ‘adaptive’ so its behavior can change over time based on new data.

Some real-world examples of artificial intelligence and machine learning technologies include:

• An imaging system that uses algorithms to give diagnostic information for skin cancer in patients.

• A smart electrocardiogram (ECG) device that estimates the probability of a heart attack.

How are Artificial Intelligence and Machine Learning Transforming Medical Devices?

Adaptive artificial intelligence and machine learning technologies differ from other software as a medical device (SaMD) in that they have the potential to adapt and optimize device performance in real-time to continuously improve health care for patients. The International Medical Device Regulators Forum (IMDRF) defines software as a medical device as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. The FDA under the Federal Food, Drug, and Cosmetic Act (FD&C Act) considers medical purpose as those purposes that are intended to treat, diagnose, cure, mitigate, or prevent disease or other conditions.

How is the FDA Considering Regulation of Artificial Intelligence and Machine Learning Medical Devices?

The FDA predicts that under its current guidance, many changes made to software as a medical device driven by artificial intelligence and machine learning would be subject to a premarket review—this has prompted the FDA to reimagine a regulatory approach for these devices.

Traditionally, the FDA reviews medical devices through an appropriate premarket pathway, such as premarket clearance (510(k)), De Novo classification, or premarket approval. The FDA may also review and clear modifications to medical devices, including software as a medical device, depending on the significance or risk posed to patients of that modification. Learn the current FDA guidance for risk-based approach for 510(k) software modifications.

The FDA’s traditional paradigm of medical device regulation was not designed for adaptive artificial intelligence and machine learning technologies. Under the FDA’s current approach to software modifications, the FDA anticipates that many of these artificial intelligence and machine learning-driven software changes to a device may need a premarket review.

On April 2, 2019, the FDA published a discussion paper “Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) – Discussion Paper and Request for Feedback” that describes the FDA’s foundation for a potential approach to premarket review for artificial intelligence and machine learning-driven software modifications.

The ideas described in the discussion paper leverage practices from our current premarket programs and rely on IMDRF’s risk categorization principles, the FDA’s benefit-risk framework, risk management principles described in the software modifications guidance, and the organization-based total product lifecycle approach (also envisioned in the Digital Health Software Precertification (Pre-Cert) Program).

In this framework, the FDA introduces a “predetermined change control plan” in premarket submissions. This plan would include the types of anticipated modifications—referred to as the “Software as a Medical Device Pre-Specifications”—and the associated methodology being used to implement those changes in a controlled manner that manages risks to patients —referred to as the “Algorithm Change Protocol.”

In this approach, the FDA would expect a commitment from manufacturers on transparency and real-world performance monitoring for artificial intelligence and machine learning-based software as a medical device, as well as periodic updates to the FDA on what changes were implemented as part of the approved pre-specifications and the algorithm change protocol.

The proposed regulatory framework could enable the FDA and manufacturers to evaluate and monitor a software product from its premarket development to postmarket performance. This potential framework allows for the FDA’s regulatory oversight to embrace the iterative improvement power of artificial intelligence and machine learning-based software as a medical device, while assuring patient safety.

Please find the complete FDA article  here.

Please get in touch with us for any further SaMD support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

According the EU spokesperson for public health and food safety, Stefan de Keersmaecker, the EU commission is working on a proposal to postpone the EU MDR by one year. This is mainly due to Covid-19 and should release the pressure on governments and manufacturers so they can focus on this crisis.

Please hear the statement of Stefan de Keersmaecker here.

The European Commission published the following statement:

“Commission working on proposal to postpone MDR application date for one year

Today (25 March 2020), the Commission announced that work on a proposal to postpone the date of application for the Medical Device Regulation (MDR) for one year is ongoing. The decision was reached with patient health and safety as a guiding principle.

The Commission is working to submit this proposal in early April for the Parliament and the Council to adopt it quickly as the date of application is the end of May. This decision will relieve pressure from national authorities, notified bodies, manufacturers and other actors and will allow them to fully focus on urgent priorities related to the coronavirus crisis.”

Please get in touch with us for any further MDR support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

PMLIVE reported in its pharma news that the US Food and Drug Administration (FDA) has approved Roche’s diagnostic test for the novel coronavirus, authorising it for emergency use. The cobas SARS-CoV-2 test is intended for qualitative detection of the novel coronavirus (SARS-CoV-2), which causes the respiratory disease COVID-19. Nasopharyngeal and oropharyngeal swab samples are taken from patients who have symptoms consistent with COVID-19, with these sample then sent to hospitals and laboratories for testing on Roche’s cobas 6800/8800 systems. These systems can produce test results in three and half hours, with a total of 1,440 results provided by the cobas 6800 system and 4,128 results by the cobas 8800 system within a 24-hour period. According to the Swiss pharma, millions of tests a month will be available for use on both systems, which it said offers improved operating efficiency and flexibility.

Please read the full article  here

Please get in touch with us for any further support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

The U.S. Food and Drug Administration is postponing inspections outside of the U.S. in response to the COVID-19 outbreak. The FDA is postponing most foreign inspections through April 2020, effective immediately. Inspections outside the U.S. deemed mission-critical will still be considered on a case-by-case basis. For medical device manufacturers based outside the US which are dependent on FDA inspections to obtain US market registration, this announcement may mean delays in premarket application reviews.

FDA states that although temporarily not being able to physically inspect foreign produced FDA-regulated products or manufacturers, as an interim measure FDA will employ additional tools to ensure the safety of products imported to the U.S., which have proved effective in the past. These include denying entry of unsafe products into the U.S., physical examinations and/or product sampling at our borders, reviewing a firm’s previous compliance history, using information sharing from foreign governments as part of mutual recognition and confidentiality agreements and requesting records “in advance of or in lieu of” on-site drug inspections. For example, FDA began exercising this authority when postponing on-the-ground inspections of manufacturers of FDA-regulated products in China earlier in the outbreak. This is all part of the FDA’s multi-pronged and risk-based approach to ensuring quality, as well as compliance, with applicable federal laws and regulations.

As this remains a dynamic situation, FDA will continue to assess and calibrate their approach as needed to help advance federal response efforts in the fight against this outbreak.

Please read the full FDA statement here

Please get in touch with us for any further support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801

Medtechdive.com reports about major global conglomerates like 3M and Philips have taken steps to increase focus on healthcare in recent years, shedding units covering other industries while buying additional medical assets in the belief the aging population will drive growth. GE took a different path, initially planning to spin off its healthcare unit (like Siemens did with a 2018 Healthineers IPO), only to decide to keep it in the fold. Across each company, healthcare is now a key element of growth forecasts, made clear during earnings reports this week.

Please read the full article here.

Please get in touch with us for any further support:

www.medsyscon.com/en

info@medsyscon.com

+49-176-57694801