We are seeing our IT/Technology work increasingly converge with our Life Sciences sector clients: our Commercial Technology team has been working on a range of IT and outsourcing deals for life sciences customers, and our Regulatory team has been advising on the regulatory issues of using new and emerging technology.

This is not surprising. The life sciences sector has traditionally seen low and slow levels of adoption of IT and outsourcing services and, consequently, there is a lot of room for growth. The main barriers to the increased adoption of IT and outsourcing services in the life sciences sector are, at their core, based on misperceptions about the regulatory environment and how it makes use of services IT suppliers typically provide, including:

• an ongoing perception that life sciences regulatory requirements impose constraints on the use of IT, technology and outsourcing services;
• outdated risk assessment practices which are often not relevant to such services, or apply in very different ways; and
• lower levels of engagement by the IT supplier community in the sector.

However, we have seen a clear upswing in the appetite of life sciences organisations to leverage IT services – a trend that is played out across the industry in other areas like the application of AI and machine learning to pharma companies’ drug discovery processes. In this piece, we will attempt to map out the regulatory framework and how it might apply to such services, and set out our thoughts on how suppliers can use this awareness to gain a stronger foothold with life sciences customers.

Summary of the regulatory environment

Virtually all aspects of the development, trialling, production, testing, marketing, distribution and post-market surveillance of medical devices, diagnostics and pharmaceuticals are regulated. In many cases (and particularly for pharmaceuticals), specific practices and common standards (e.g. the ‘GxP standards’) have been codified to assist with compliance.

These requirements are increasing. Some of the standards have regulatory status while others are merely “strongly recommended”. It is widely accepted that these changes will result in the withdrawal of at least 40% of existing medical devices. We regularly write about various demands imposed by the pending European Medical Devices Regulation (MDR) (and other life sciences sector issues) in our dedicated life sciences microsite, On The Pulse.

Application to IT & outsourcing services

Pharmaceutical and medical device companies are increasingly reliant on IT solutions for the development, manufacture, distribution and monitoring of their products. They must ensure that their IT infrastructure meets relevant regulatory requirements and that any changes are validated before implementation. If it becomes clear (e.g. in an audit) that a medical device or pharmaceutical company is reliant on inadequate IT systems or software, the consequences can include recalls, suspension of sales while a new approval is obtained, or the deployment of a patch with inevitable downtime for customers and patients.

Life sciences companies are therefore increasingly asking IT service providers to provide their products and services in accordance with regulatory standards and guidelines (e.g. GxP standards). This approach is not usually an acceptable “compliance with law” position for a supplier, and for the customer we think this high-level approach often does not actually deliver the required compliance. Customer compliance is more nuanced – it requires more thought as to the applicability to the services in question and, if relevant, a considered flow-through of appropriate terms and rights into the contract. As the following two examples show, it is not sufficient for the customer, nor appealing to the supplier, to include a broad high-level requirement to “comply with GxP standards”, etc.

An IT supplier may provide hosting and support services for a life sciences customer across a suite of applications and data, which support the customer’s GxP compliance. GxP standards may require the customer to have readily available access to its data systems that handle regulated data (e.g. clinical trials or patient data). The supplier may propose its standard solution that works in other industries, but the life sciences customer will need to conduct a gap analysis to work out whether the proposed solution/functionality meets its regulatory need for data access. If it does not, the customer may need to set out its specific technical requirements that meet its regulatory need. In the case of data access, it could be that the service needs to allow the customer to extract its data at any time, which may require a different systems architecture (e.g. APIs and extraction tools). The supplier will understand the technical requirement and will usually be able to design it into a tailored solution for the customer.

Another example that is increasingly relevant to life sciences companies is cybersecurity. The concept of cybersecurity by design (introduced by the European Commission’s December 2019 Guidance on Cybersecurity) applies to all medical devices currently on the market. It requires reverse engineering of cybersecurity requirements and imposes particular cybersecurity requirements on life sciences organisations. Many organisations will have custom system security plans that set out how they comply. Again, they will need to verify and validate that their IT supplier’s cybersecurity approach enables compliance. Where the customer is an NHS entity, it is likely to ask the supplier to comply with a wide array of regulations and guidance. This should be considered very carefully and in many instances new regulatory requirements should be the subject of change control.

As the above examples show, it is often not necessary (or even recommended) for IT suppliers to take on broader contractual obligations to help life sciences customers address their regulatory compliance issues. Rather, both parties need to better understand issues to assist in internal discussions (e.g. solution design, delivery requirements) and customer negotiations (to avoid full risk-transfer and reach nuanced provisions that drive practical compliance).

“Healthtech” solutions and the regulatory implications

In addition to the regulatory impact on IT/outsourcing contracts, it is increasingly common for technology design, build and implementation services, used in direct healthcare provision, to fall directly within the remit of healthcare regulation. Examples include app-based health platforms like GP On Demand, AI algorithms like those used by IBM Watson Health and diagnostic tools like vital signs detection systems. We regularly encounter companies that may have developed (or modified existing) products or offer integrated solutions without realising that the product or solution that they wish to commercialise is actually an unauthorised medical device.

This is particularly common where an existing product is modified to add functionality which causes the product to “cross the line”. This can arise where a simple electronic data capture system is modified to add an alarm or suggest that the user Check with your Doctor in response to a data input. A product does not need to make a binary diagnosis in order to be considered “diagnostic”: merely making a prediction or a prognosis or suggesting a range of responses may suffice.

For IT suppliers, this type of risk may be more likely to arise in application development projects for the NHS (e.g. individual Trusts, NHS Digital, NHSX) or other healthcare providers or producers of diagnostic tools like the big pharmaceutical companies, where the supplier’s use of proprietary systems coupled with bespoke ‘green field’ application development is used by the customer to operate a healthcare system or service. By providing such services, the IT supplier could easily find that its system is classified as a medical device and therefore subject to a complex regulatory approval process and ongoing post-market surveillance.

This regulatory risk is in addition to the risk that systems might also be seen as ‘safety critical’, in that they carry the risk that faults or misuse may cause harm to individuals (e.g. a diagnostic tool that produces defective results, which are relied upon to provide ineffective or dangerous treatment). Such safety critical risks may already apply, depending on the scope, to other areas of the supplier’s business, such as business process services that help fulfil a healthcare customer’s activities or application management services that support a customer’s key systems.

Suppliers designing and implementing such systems should carefully consider whether it may constitute a medical device and seek specific advice at an early stage to either avoid this, or to ensure they can seek appropriate certifications and comply with medical device law. This is therefore less of a contractual or negotiation issue with any one customer, but is more of an internal compliance issue.

Conclusion

As the above examples demonstrate, it can often be unclear whether and how life sciences regulation may apply to any particular IT service, outsourced function or technology system. However, it is becoming increasingly clear that the approach to addressing regulatory compliance at the convergence of Life Sciences and IT/Technology has not traditionally been done well. More engagement and understanding is needed by both the sector and the suppliers to it, to take full advantage of the range of IT, outsourcing and technology solutions available in the market.