The internet is on fire with recent news of a new security vulnerability identified in Apache Log4j.

Log4j is an open-source logging framework used by major Java-based enterprise applications and servers. The vulnerability is being considered as one of the most dangerous ones found in recent years. It potentially allows attackers to execute arbitrary code within a company’s network by sending crafted log messages. It has been identified as CVE-2021-44228 and called Log4Shell.

Security-mature organizations started assessing their exposure almost immediately due to the severity of the exploit and provided security patches or workaround solutions to safeguard systems and data from this threat.

In life sciences, we quickly reacted to the issue, identified the resolutions for the respective products of different versions, and developed an action plan immediately for cloud hosting customers.

In close collaboration and coordination with our customers and their users, we were able to patch and protect against this vulnerability for all our life sciences hosted clients within a few hours to safeguard each hosted application.

This is the final post in our series on maintaining regulatory-compliant IT systems in the cloud. In this post, we’ll go over the key takeaways from the series and then we’ll send you on your way!

Regardless of how much control you have over your IT systems, if you are using them for regulatory purposes, it is your responsibility to ensure their compliance. This reality, however, should not deter you from adopting cloud-hosted systems, as their benefits are undeniable. Rather, be smart about how you select and manage them.

To make the most of the cloud, while maintaining regulatory compliance, you need a robust cloud vendor qualification procedure and a regulatory expert involved in your contract negotiations. Key topics include:

• Physical security
• Data security, privacy, and confidentiality
• Technical support, including enhancements
• Uptime, including backup and recovery
• Data mobility
• Regulatory compliance, especially change control
• How the cloud vendor qualifies the cloud vendors it uses (e.g., data centers)

Additionally, be thoughtful about which tools you use in your cloud vendor qualification process, aligning the tools with the criticality of the system being selected. And, finally, ensure you have the appropriate application-level and quality assurance procedures in place to support the use of each system, once it has been validated and release for production use.

And that’s it! You made it through the series. If you haven’t yet downloaded your copy of the guide on this topic, be sure to fill out the form below. If you have any questions about any of the content of these posts or the guide, or if you need help assessing and resolving compliance issues with cloud vendors, please let us know! We always love hearing from our readers.

As we’ve learned in the previous posts in this series, having a thoughtful, thorough cloud vendor qualification process and intelligent SLAs in your cloud vendor contracts will help you maximize the value of the cloud while maintaining regulatory compliance. In addition, here are some tips and best practices to help you knock it out of the park.

Cloud Vendor Qualification Tools

When qualifying cloud vendors, there are several tools you can use including audits, questionnaires, investigating publicly available information, and checking references. Because audits are time-consuming and expensive, you might want to reserve them for systems you deem “critical.” For less-critical systems, reviewing a completed questionnaire might be sufficient.

To conserve resources, you will want to use a risk-based approach when selecting qualification tools. Consider defining system criticality tiers somewhere in your SOPs, and then creating a kind of matrix that aligns the types of qualification tools with each tier of criticality.

As a point of clarification, the topics you cover in your qualification process will be the same across all cloud vendors/systems. What will differ is the set of tools you use to learn about those topics.

Additional SOPs

Your cloud vendor qualification SOP will help you select an appropriate system for regulated purposes, but is not the only SOP you need for a service in the cloud. As with any regulated software or hardware, you still need documented procedures that address business use and quality assurance (QA), especially computer system validation (CSV) and change control.

As a general guide, the cloud vendor will own the technical procedures (which you will qualify during cloud vendor selection and enforce in your SLAs), and you will own the application procedures, with quality assurance procedures overlapping.

Okay, almost there! Just one last post in this series. If you haven’t already, feel free download the guide on this topic by filling out the form below. See you soon!

In my previous post in this series, we discussed how to qualify cloud vendors. Once that process is complete, the second step to maintaining compliance is to document your specific regulatory requirements in a contract with the cloud vendor, usually in the form of service-level agreements (SLAs). In this blog post, I include a range of questions you might consider throughout this process.

Similar to the key qualification topics, you will want document SLAs in the following areas, including what the cloud vendor is committing to, what happens if it do not keep those commitments, and which party – you or the cloud vendor – is responsible for what.

Uptime / Downtime

• What is the minimum percentage of uptime you can expect?
• Are there specific times when downtime is expected? If so, what times and how often?
• If the downtime goes beyond the agreed upon percentage, will you be compensated in some way?
• If the system fails, how quickly will the cloud vendor commit to getting the system back online?

Backup and Recovery

• How often does the cloud vendor take backups? Is it real-time mirroring or periodic snapshots?
• How quickly can lost data be restored?
• If any of your data is lost, will you be compensated?

Security

• What will the cloud vendor do to proactively protect security, and what will it do if security is breached in some way? This includes: physical security, cyber security (e.g., viruses, hacking, phishing), employee sabotage, fraud, theft of data, etc.

Data Storage, Location, and Ownership

• How long will your data be stored, and does that duration comply with all governing regulations?
• What exactly will the storage cost, especially as you amass data over time?
• Exactly where will the data be stored (including the country)?
• Will your data be segregated from or comingled with other companies’ data?
• Who owns the data (this needs to be you, in order to be regulatory compliant)? Do they have the right to keep a copy?

Performance Monitoring

• What performance thresholds does the cloud vendor use?
• What is its response time when a threshold is breached?
• At what point is capacity added?
• Are you able to receive any performance-related reports?

Service Termination

• If you need to part ways with the cloud vendor, are you able to terminate your service without penalty?
• How will you extract your data in a regulatory manner and format?

Defect Management

• What is the cloud vendor’s escalation process for defects?
• How quickly will it commit to resolving the issue?
• If another company reports a defect, will you be notified?

Change Management

• How much advance notice will you receive when changes (e.g., patches, bug fixes, minor releases, major releases) are planned?
• Will you receive a test environment in advance of the change with enough time to fully test and assess the impact?
• If your testing reveals issues, will you have the option to stay at the current version, or at least delay the upgrade until the issues are resolved? If the answer to any of these questions is no, the cloud vendor might not be suitable for regulated/validated systems (infrastructure, platform, or software).

Regulatory Compliance

• If any of the governing regulations change, is the cloud vendor committed to getting the system compliant prior to the effective date of the changes? As with change management, if the cloud vendor is not able to make this commitment, it might not be a suitable choice for a regulated/validated system.

While this is not meant to be an exhaustive list, I believe it’s a good place to start. However, I ask that you remember I’m not a lawyer, so please don’t take any of this as a form of legal advice.

As we wrap up this series (just a couple of posts left!), we’ll leave you with some tips and best practices, as well as a summary of the key takeaways. While you wait, just fill out the form below to download our comprehensive guide on cloud compliance.

We recently completed a 21 CFR Part 11 gap analysis engagement for a client that was largely using SaaS applications, but had no cloud vendor qualification process in place. They had just been allowing each business unit to select the applications that met its user requirements, accept whatever validation documentation the cloud vendor supplied (if any), and trust that the cloud vendor had been thorough and compliant.

Unfortunately, this approach doesn’t fly with auditors, nor does it protect companies and their data from risk. Because the ultimate responsibility for regulatory compliance lies with you – the pharmaceutical or medical device company – you need to be much more proactive and critical.

Your documented cloud vendor qualification standard operating procedure (SOP) must describe how you verify that a cloud vendor holds itself to the same degree of compliance as you would hold yourself, if you were building and/or hosting the system. It must also describe how you ensure the cloud vendor maintains those standards over time.

When qualifying a cloud vendor, be sure to evaluate their written procedures and the documented evidence that they follow their procedures in the following key areas:

• Security of the physical space, which houses the servers that host IaaS, PaaS, and/or SaaS products, even if that space is in a third-party data center
• Security, privacy, and confidentiality of customer data
• Technical support, including enhancements for PaaS and SaaS products
• Availability or uptime of its products, including backup and recovery processes
• Data mobility (i.e., options for extracting your data out of their product in a regulatory compliant manner and format)
• Regulatory compliance, specific to your company’s needs and operating locations (e.g., 21 CFR Part 11, Annex 11)
• Change control procedures for its products. Specifically: How is a change authorized? How is a change documented? Is an impact assessment performed, prior to making a change? Is adequate testing performed, prior to releasing a change? Are customers notified in advance of a change? Is a test environment provided to customers in advance of a change? What options do customers have if a change breaks existing functionality or creates a compliance risk?
• How the cloud vendor qualifies the third parties it uses, including data centers

Additionally, you want to consider each cloud vendor’s longevity. How long has the cloud vendor existed? How stable does the company seem to be? And, of course, you will want to speak with other companies using the product(s) you are considering, ideally for similar purposes, to get a feel for their satisfaction with the cloud vendor.

Finally, your cloud vendor qualification SOP should also include a periodic re-qualification process to ensure the cloud vendor continues to maintain the standards you originally verified.

If at any point – either during initial qualification or periodic re-qualification – a cloud vendor does not meet your minimum requirements, you have two choices: negotiate with the cloud vendor to revise its procedures to meet your needs, or walk away. The latter option is more complicated, if the failure occurs during re-qualification, but that is why it is critical to verify data mobility during the initial qualification.

Up next in this series on regulatory-compliant cloud systems is a detailed look at protecting yourself with contract terms or service level agreements (SLAs). In the meantime, feel free to download our guide on this topic – just fill out the form below!

Any time you take advantage of a cloud service – infrastructure, platform, or software – for a regulated purpose, you are ultimately responsible for its regulatory compliance, not the cloud vendor. This is critical for you to remember.

So, how can you ensure regulatory compliance of a software system you did not build, you do not host, and you do not own? There are two keys to doing so effectively:

1. Qualify your cloud vendors before selecting them (and re-qualify them over time)
2. Be incredibly smart about your contract terms

In the next two posts in this series, we’ll look at each of these items in depth. If you can’t handle the suspense, just download the complete guide by filling out the form below. Chat soon!

As we continue our series on maintaining regulatory-compliant cloud systems, let’s touch on a few key terms. Below are explanations of the primary cloud-hosted offerings available in the market.

Infrastructure-as-a-Service (IaaS)

When you purchase a software system and opt to have a vendor host it for you instead of installing it on servers you own, you are experiencing Infrastructure-as-a-Service (IaaS). The hosting vendor is likely to rely on another vendor, a data center, as part of its hosting service. Data centers also fall under IaaS.

Platform-as-a-Service (PaaS)

When you build custom applications on a software platform that is hosted in the cloud (e.g., Salesforce, Appian), you are using a Platform-as-a-Service (PaaS).

Software-as-a-Service (SaaS)

A cloud-hosted software system that was not built or designed specifically for you is called Software-as-a-Service (SaaS).

If your company is regulated, and you use any of the above for any regulated purposes, these cloud “services” are also subject to the regulations.

Throughout this blog series, we’ll refer to the providers of these cloud services as “cloud vendors.”

Check back soon for the next post in this series: who is responsible for compliance, the customer or the cloud vendor? While you wait, you can read our guide on this topic by filling out the form below.

If your company makes drugs, medical devices, or biologics (vaccines, blood and blood components, allergenics, somatic cells, gene therapy, tissues, and recombinant therapeutic proteins), it is regulated.

If your company is regulated, then every IT system you use to design, develop, conduct trials, manufacture, package, label, store, distribute, install, or service your products is also regulated and must comply with the regulations that govern the countries and regions in which your company operates. This includes both IT systems you host on your own premises, as well as those available in the cloud.

With this in mind, we’ll move on to the next post in this series on maintaining regulatory-compliant IT systems in the cloud. Between now and the next post, feel free to download the related guide by filling out the form below.

The benefits of cloud hosting – including Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) – are very clear: less upfront capital, faster implementations, scalability and elasticity, and no need for individual companies to maintain physical space, hardware, and/or technical staff for support.

But there are also several risks to consider, including physical and technical security, privacy and confidentiality, technical support, enhancements, application uptime/availability, vendor stability, and data mobility – the ability to extract data from the system. In industries like life sciences, the stakes are even higher because the systems used for regulated purposes must comply with the governing regulations.

The benefits of the cloud are so compelling that it is simply not practical to avoid it altogether. In an upcoming blog series, we’ll help you make the most of what the cloud has to offer, while still maintaining regulatory compliance.

Check back in a few days for the next post in this series – a refresher on which IT systems are regulated. In the meantime, you can download our guide on this topic by filling out the form below.

Now that April is here, I thought it would be neat to look back at what our readers found most interesting last month. Below are the top five blog posts Perficient’s life sciences practice wrote in March – they’re ranked in order of popularity, with number one being the most viewed piece.

1. Collaboration In Pharma Is Surging
2. How To Override The Default “Primary User” In Siebel
3. How To Free Up Disk Space For The Installation Of Siebel IP2016
4. What Is OracleXEConfig?
5. Argus Safety, Oracle Clinical & RDC Release Notes [March 2018]

As always, thank you for your continued support – our team finds it very rewarding to have you as a reader.

Artificial intelligence (AI), cognitive computing, and machine learning are becoming more common in the industry. The need to scour and analyze large sets of data is giving life sciences companies new intelligence that would never have been realized before. The technology is making a big impact on healthcare decisions and patients.

When it comes to addiction and substance abuse, patient risk models are helping predict and prevent incidents of relapse. Artificial intelligence is helping doctors identify treatment options while providing supporting evidence. While AI is driving precision medicine, it’s also being used by pharmaceutical companies to gain insight into consumer behavior and expectations.

Jason Andree, senior brand manager of the Cough & Cold Portfolio at GlaxoSmithKline North America, shared how GSK is using cognitive technology to promote its Theraflu brand. The company is using IBM Watson to enable consumers to interact with advertisements within a mobile app, by asking questions (through voice or text) related to the flu or the Theraflu product.

To learn about other trends that we can also expect to see in 2018, click here.

The industry continues to flex its muscle when it comes to innovation through the use of digital technology. While life sciences companies over the years have tended to be laggards in this respect as compared to other industries, they’ve really come to understand the importance of using digital technology. It’s a necessity. It’s an integral part of their programs. Companies realize the new ways their patients are communicating and the high expectations they maintain because of the digital era in which they live. They also understand how, through the use of digital and mobile devices, healthcare outcomes can dramatically improve.

Whenever a large company appoints a new chief, it’s an important headline that may highlight the company’s ambitions, strategic direction, and intentions. So, when a top pharmaceutical company hires a new chief of digital, it’s difficult to overlook the critical role digital plays in life sciences.

That’s exactly what happened at GlaxoSmithKline in 2017. The company appointed Karenann Terrell, who previously served as the CIO of Walmart. When you bring an executive from the world’s largest (by revenue) company, which happens to focus on selling directly to consumers, good things should happen.

Novartis is another example of a large pharmaceutical company that is increasing its focus on digital. It recently hired Bertrand Bodson as the company’s chief digital officer. Mr. Bodson was the chief digital and marketing officer for Argos, the third-largest online retailer in the UK.

While bringing a leader from outside the industry can often shape a company’s appetite for digital, life sciences organizations have already proven their aptitude for innovation and technology. Innovative mobile apps and digital devices meant to educate, increase adherence, and provide clinical, safety and healthcare professionals with more (and better) data are being developed at an increasing rate.

Hemocraft, a game based on Minecraft and developed by Pfizer in partnership with Drexel University and the hemophilia community, aims to help young people with hemophilia understand the need for integrating treatment into their routines. Users of the game learn what treatment entails and how to stick to a treatment plan.

The HemMobile Striiv Wearable, a wearable device for patients with hemophilia, was created this year to track activity levels and monitor heart rate. The bracelet feeds data into a complementary app, which can give healthcare professionals better insight into patients’ conditions.

While paper has been the primary means of data collection for over a decade, the creation of new apps enables patients to report symptoms in real time. This digital and remote way of collecting data can save patients and healthcare providers a significant amount of time and increase the accuracy of data. With today’s devices, one doesn’t have to remember how he or she was feeling at a particular point in time.

Kenneth M. Farber, co-CEO and co-president of the Lupus Research Alliance, highlighted an app the organization created, alongside Pfizer, for lupus patients.

“This is an important step in demonstrating that mobile technology can improve how and what patients report to their care teams about subjective but serious symptoms of lupus, such as debilitating fatigue,” he said. “This app may enable more frequent and consistent reporting from patients, thus providing better information for care teams and empowering patients to take a larger role in developing future therapies.”

With each passing day, companies are developing better ways to monitor health conditions. Where in the past, patients would need to be in a doctor’s office or hospital with large equipment at their side, mobile has now enabled taking monitoring on the go.

Abbott’s Confirm Rx Insertable Cardiac Monitor (ICM) is a great example. It’s the world’s first smartphone-compatible ICM that automatically gathers vital cardiac information and delivers the data to physicians via the myMerlin mobile app, providing the ability to monitor heart rhythms remotely.

Sanofi’s My Dose Coach is another wonderful example of a how a mobile app can improve patient safety and medication adherence. The app, created for adult type 2 diabetes patients on once-daily, long-acting basal insulin, can calculate the patient’s recommended basal insulin dose according to the dose plan his or her doctor has created. The patient simply enters his or her fasting blood glucose and gets a recommended basal insulin dose.

To learn about other trends that we can also expect to see in 2018, click here.