Software as a Medical Device Innovation

It may be said with some certainty that last year many gradually slipped into insanity. The timing could not have been worse for multiple industries which scrambled to find alternative measures to counter the irregular pandemic.

Europe and the UK have been economically infertile for much of the past ten months, yet, behind the scenes, investment in the Medical Device arena has silently expanded.

This is no surprise. We have seen throughout the last ten years, outbreaks of popular interest in digitised Medical Devices.

From 2021-2022, I expect to see more investment and innovation.

Advancements in securely transferring and scaling sensitive data both backwards and forwards from Medical Devices alongside personal devices have in due course, opened up more doors. Such new standards have brought opportunities to settle old technical problems. Old technical problems which once held back the industry are now a thing of the near past.

To add more positive news, intensive heavy-handed regulation has been chopped away, albeit slowly. Although it may provide instant transformation, this does offer more tailored approaches for organisations and businesses for specific international obligations and targeted user groups.

But as we move into a new decade, what will this all mean for the remainder of the Medical Device industry?

SaMD vs Non-SaMD: Advancements & Convergence

As already mentioned, the last ten years have witnessed a great proliferation of software used in and around medical devices.

As mentioned, the medical device industry has gone through an acceleration in this area thanks to the emergence of improved networking and cybersecurity standards.

Besides, there has been the further widespread availability of commercial Off Shelf (OTS) software that has contributed to such innovation.

Other sources of innovation have been due to more significant advancement though. If we take a step backwards and climb higher up the tree for a wider view, the technical advancement of personal computers, smartphones, virtual networks, wireless connectivity, sensors, cloud computing, big data analysis and Artificial Intelligence (AI) with an emphasis on Machine Learning (ML) - have all silently transformed how labour and interaction are accomplished throughout all major industries, including the Medical Device sector.

The Medical Device industry was slow to adapt to such technological advancements and for many commentators on the outside, this made some sense. As with such high risk involved, the most sensible route to take was to "wait it out" or heavily pilot to identify the real worth of such advancements.

Fast forward 5 years and it has become apparent for many of the sectors big organisations that there is definite value to be utilised.

As a result, the sector faces a dilemma: technical advancements are moving and progressing much faster than regulation and compliance legislation. Metaphorically speaking, the hand has become too big for the glove.

With software progressively becoming a crucial component in medical devices and even more pervasive in the healthcare industry as a whole, experts in the field are looking to alleviate pressure and find more systematic approaches to foster and accommodate technological advancement safely and securely.

This nod of approval has ignited two key developments in the progression of Medical Devices: “Software as A Medical Device” (SaMD) and “Non-Software as A Medical Device” (Non-SaMD).

Although these terms are not set in stone, they do convey what is currently disrupting the international market.

Software as A Medical Device (SaMD)

SaMD represents the more conventional type of Medical Devices with embedded software, this may be glucose detection devices or active patient monitoring equipment.

In short, SaMD has higher quality performance standards and obligations. Hence, why risk management is incredibly important for SaMD. Any potential defects in terms of quality and design, performance or functionality of SaMD can have drastic consequences on public health and safety.

Finally, the sole purpose of SaMD is to display and visualise important patient data. The modification or manipulation of data would be out of scope here, although, there has been a further debate within the industry to classify modern SaMD under different terms.

Non-Software as a Medical Device (Non-SaMD)

Non-SaMD more or less utilises what experts call “Connected Health”, this being a device that is connected to a digitalised platform and can be reached from multiple end-points.

It's not so much focused on pure patient monitoring. It's bound to more digitalised offerings and solutions, such as mobile applications or smartwatches which are connected to a digital platform. Data is usually calculated and retained, even geographical data.

Frequently there are metrics used to guide a Graphical User Interface of such a solution. Industry players are often able to produce Non-SaMD offerings at a faster pace due to less stringent regulation and risk management obligations.

To simplify a bit more, the data collected for SaMD drives patient monitoring and manufacturing whilst the data collected for Non-SaMD drives and guides the configuration and interaction of a connected product.

What awaits in the future?

It would be too naive to simply claim that such advancements as these will inevitably bring forward regulation x compliance or risk management strategies for manufacturers and software houses up to speed.

Currently, this is not the case. The process is still constrained. Automated analysis and real-time collection of sensitive data come with a range of ethical standards and expected obligations on behalf of the business or organisation manufacturing such devices and equipment. The workload is still abnormally large.

Yet, outside of the industry, social discord appears to be adapting itself to such measures. This eases certain barriers and fosters market needs and wants tremendously.

The pandemic, no doubt, helped bring such changes of behaviour forward in double time and a majority see great value in the digitisation of Medical Devices (SaMD).

Therefore, with momentum now in full swing, both the industry and regulation and compliance authorities appear to be producing legislative measures at a more productive pace.

A select batch of future opportunities

The industry appears to be opening up and therefore, vigorous and systematic developments within regulation and compliance will also open up more opportunities to innovate, rather than suffocate.

Improvements like these, albeit small improvements right now, can only be seen as a positive. But grey areas remain.

Regulatory authorities will have difficulty in classification and scope as the more Non-SaMD developments progress and inter-weave between our daily lives.

As more and more people find means to apply Non-SaMD in their lives, this will create classification and risk fragmentation, this being risk which is difficult to wholly generalise and apply generalised systematic guidance and regulation.

This being said, the next 5 years will see more improvement with regards to baking regulatory and risk management strategies into the software development process. This is a very positive outlook. I expect to see more harmonisation between these two spheres as the market demand increases.

Here are some additional challenges and opportunities that we can expect throughout the next decade:

1. Automating Software Development Deliverables

With the help of modern automation tooling, as in automating specific routine tasks involved throughout the software development lifecycle, many will be surprised about how much documentation can already be continuously improved upon with little involvement from personnel on the ground. Large and distributed organisations, in particular, must look for ways to introduce automation into the documentation process.

A great example is using runbook or code examples in a development guide or even better, for example, code demonstrations in Data Protection Impact Assessments (DPIA).

There are tools like Selenium for basic use-cases that involve extracting code snippets from functional UI codebases, or straight from a Continous Integration (CI) Pipelines (i.e. automated integration and testing of new code commits) to be embedded into the organisation's expected software deliverables documentation.

As both SaMD and Non-SaMD convergence and become more prevalent within the industry and peoples lives, no doubt, regulators will be hoping to see more transparency with regards to actual working code.

Another area of opportunity using automation would be to enable code to influence and feed realistic metrics for risk management.

Coming back to CI Tooling, such technology can help funnel data that can be reused for software code review practices, or even monitoring software system requirements.

There are potential options available for organisations to monitor the CI pipeline and leverage its success rates to discover where potential vulnerabilities throughout a software system are occurring ahead of time.

Teams would need to cluster common or irregular issues found, categorise and semantically collect sequences of events that are inconsistent or stick out from the crowd.

Once accumulated, the metadata would help identify potential areas of the complete software system that ought to be superimposed and equalled out from a risk perspective.

This activity in itself can likewise help guide and shape deliverables such as risk management or cybersecurity assessments, for example.

Although this suggestion may not be as straightforward as it sounds, there are initiatives already taking place and a keen interest in technological feedback loops taking place around the industry.

2. ML for Internationalisation

Believe it or not, localisation, this being the translation of a GUI's content from one language to another presents many technicalities and nuances that can often be very problematic for organisations or businesses that are not prepared to accommodate such practices.

Throughout the last 15 years, Medical Device manufacturers and software houses have only considered the target audience and market route to determine the preferred language of choice.

If the market route is Japan and only Japan, then all focus should be on composing and creating a GUI and system for Japanese audiences and users. This simplifies the process moderately.

Furthermore, if the market route is a specific customer of the manufacturer, this also makes life considerably more comfortable.

Moving forward, with the rise and convergence of Non-SaMD which offers more digitised platform-based solutions, target audiences will become more diverse.

Already, it is increasingly difficult to tailor platforms and applications which may be easily accessible from where every user geographically lives.

International app stores with downloadable solutions or bundles also make such tailoring of localisation difficult. Add to this, that a majority of international countries habitually accommodate citizens from all across the world with various diverse mother tongues, the process becomes extra sensitive.

For the healthcare industry, localisation can be a very sensitive matter indeed. In particular, a majority of people often prefer to converse and interpret sensitive health information in a language in which they feel most comfortable.

As it stands, there is no doubt, that as digitalised Connected Health solutions become more popular, localisation will become incredibly important and perhaps, be higher up on a product owners agenda soon.

For those willing to adapt, will probably find great discoveries when leveraging automation techniques.

Organisations and businesses within healthcare and the life sciences, in general, are only just beginning to recognise how designing and building software healthcare solutions with modern localisation capabilities is going to be a very rewarding exercise.

Certain elements of languages and localisation we can manage and automate, take, for example, gender-sensitive components of a language's grammar or colourisation.

Dates, times, and currencies are components of a language we shouldn’t have to handle manually and, instead, there are readily available OTS libraries.

However, organisations and businesses are often burdened by having to maintain and tailor aspects of these third-party OTS libraries themselves, if they are not careful.

ML as a branch of AI has come into the foreground in a lot of different areas.

Localisation and translation are not detached from that. Think of companies like Amazon or eBay: who both translate millions of lines of content every day, and with such quick turnaround times, that there’s no way a human could handle such activities manually, no matter how good the core software engineers may prove to imply.

Machine translations are a significant trend, and this offers a huge opportunity to cut costs and increase efficiency.

By and large, however, we have still got miles to go in terms of achieving a richer and broader availability of support, particularly for what experts figuratively call “minority languages”, the thousands of languages that exist outside of the core 50 or so that are broadly spoken and in no danger of extinction.

English continues to be the current lingua franca of the international market but I have no doubt this will change as localisation becomes more and more prevalent throughout core software and digitalised solutions.

3. The Rise of Wearables

With particular emphasis on Non-SaMD solutions, as well with the rise of Connected Health Web and Mobile Applications, regulators and international standard authorities have been quick to ensure the regulatory scope is rather narrow.

In practice, organisations, businesses and manufacturers were simply forced into a corner to remove certain feature-enriched capabilities from mobile devices and apps as a result.

Coming back to my point from earlier, this perhaps, was a wise move to momentarily pilot and analyse how such advancements were going to play out with patient risk so high.

However, for organisations such as Apple, who were looking to push the envelope rather early, their hands were tied when they removed sensors for a majority of their Connected Health solutions to ensure compliance.

What is more, products were limited in features and capabilities, turning away potential users. By and large, Android was at the time not as stringently regulated, therefore, more scope was available and Andriod applications and devices indirectly benefited.

As expected, the FDA has since started taking Non-SaMD (Connected Health ecosystem) seriously. Every effort was made to provide incremental issuing of supplement guidance to clarify their regulatory stance on health-tracking wearables such as smart-watches.

With enough financial and regulatory accommodation, we can expect further disruption in the market here.

Cybersecurity standards are also having to accept contexts such as smart-watches or wearables, something in the Medical Device Industry we now label as Bring Your Own Devices (BYOB).

This means that manufacturers and software houses will be able to fully equip personal mobile devices and smart-watches alike with sufficient levels of protection.

As Connected Health solutions generally combine several medical devices, this does emphasise the importance of patient care.

This will present opportunities for Connected Health research and development in terms of regulation, standards, design and software development in general.

What is more, we shall see more equalling out of Connected Health or Non-SaMD solutions and products with extensive user-centred feature-rich capabilities.

Human-centred design and implementation principles have long been applied in high-hazard industries such as aerospace, nuclear, petrochemical, energy and transport to minimise potential risks.

Increasingly, with wearables and smart-watches, as well as Connected Health solutions using mobile applications on the rise, human-centred design and implementation in healthcare and medical devices will become recognised as an important and in-demand topic.

4. Inclusive Hybrid Delivery-Model Strategies

Large international organisations are continuously faced with the "move slow to adapt and break nothing vs move fast to adapt and break everything" dilemma. It reoccurs time and time again.

Such a dilemma has significant implications for how operational and cultural changes occur. Often, when organisations adopt a Quality Management System framework internally, sceptics will be quick to acid-test universal expectations.

This is only natural and as a result, many organisations adopt a QMS to bolt onto an existing and working V-model workflow to help cushion regulatory and compliance.

However, as Agile workflows are the foundations for modern software development and manufacturing in other similar essential industries, the healthcare sector remains undecided on how best to accommodate Agile practices alongside QMS frameworks in its totality.

It can be safe to predict, that more and more organisations will be looking for ways to hook in modern Agile practices and values into their existing software development lifecycles and parallel regulatory processes.

There are many ways to do this and small workforces often are issued to work internally to help rupture and influence change by creating more sophisticated hybrid Agile V-models instead of relying on the classic SAFe and Waterfall models.

Hundreds of influential Medical Device organisations typically follow the V-Model. As a result, they are already familiar with the structure and phases of the V-Model and therefore, in theory, they would be more willing to adopt a hybrid model based on Agile Development Processes.

In fact, many if not all organisations and businesses are already familiar with Agile Development Processes but have had little room to accommodate further.

There is no obvious logic for saying that this particular want and need will not continue. Organisations and businesses will be looking for numerous tangible opportunities to accelerate such change throughout the next 5 - 10 years.

5. Data Protection: Harmonisation on International Legislation

What boundaries are involved or to be established for personal patient data? Can these boundaries be re-constructed at will? When does personal data no longer become classified as personal data under the confinements of law and legislation?

These are just a few thought experiments that appear to be rising to the surface within the industry.

Connected Health Non-SaMD offerings and applications are now obliged to follow modern Data Protection Standards.

In Europe, we are obliged to follow the GDPR.

Leaving this aside for a moment, over the past 5 years, there has been much debate amongst international courts as to what legal grounds can be applied for lawful processing of personal data. Under the GDPR, it was first proposed that the processing of personal data is allowed on the basis of 6 legal principles.

It is immediately obvious that Data Protection is at present, an important technical and operational factor organisations need to recognise if they wish to be taken seriously.

Yet, the overall legislative stance has been for some time, a little fragmented. In the United States, data protection is part of the right to privacy (in Constitutional and tort law) and subject to sectoral legislation, notably with regard to finance, healthcare, special protection of children, and consumer protection.

There is no general law on data protection, apart from the 1974 Privacy Act (which only applies to Federal Agencies) which overlaps with the Computer Matching and Privacy Protection Act of 1988, P.L. 100–503.

One could say that whereas in the United States the processing of personal information is allowed unless it has been explicitly restricted, in the EU any processing of any personal data in any context is conditioned by a set of rules and legal grounds that impose obligations on those who process data and attribute rights to those whose personal data is at stake.

It would, I should imagine, be impossible to say that more international legislative harmonisation with regards to Data Protection will have to occur in order to truly enable the Life Sciences & Healthcare, especially within the context of Connected Health - to blossom into maturity. Organisations and businesses are already employing workforces to help with such an agenda.

These are workforces that are focused on authorising the real-time collection of sensitive patient data ensuring objective and non-discriminatory criteria have been provided for collecting and retaining. With such initiatives underway, greater regulatory transparency on Data Protection is urgently required.