The life sciences industry is subject to significant regulation, and it’s on the rise. Due to an increasingly complex global regulatory environment, most companies and organizations have adopted vigorous software & hardware selection and implementation practices.

The life sciences industry as a whole is almost completely dependent on information technology. From data collection and data analysis to drug/device manufacturing and point-of-care delivery, both software and IT infrastructure play a vital role in the medical advances we’ve made – and in healthcare delivery.

Complex regulatory landscapes are an issue that routinely impacts software selection, modification and customization in the pharma, biopharma, medical device and diagnostics industries.

Regulated Software

In the last 12 months, the FDA has issued guidance to improve clarity around what particular types of software constitute medical devices in their own right. From 

On December 8, 2017 – nearly a year after President Obama signed into law the 21st Century Cures Act (“Cures Act”) – the Food and Drug Administration (“FDA”) released two new draft guidances that aim to implement section 3060 of the Cures Act, and provide clarity on the Agency’s regulatory approach to software as a medical device. As explained in a statement by FDA Commissioner Scott Gottlieb, the new draft guidances “offer additional clarity about where the FDA sees its role in digital health, and importantly, where we don’t see a need for FDA involvement.” 

Software, however, need not be considered a “regulated product” in order to fall under a regulatory purview.

Are you ready? Download our checklist.

Review a short list of things that must be considered by Executives in regulated industries when planning the development of a custom software solution.

Recognizing the Risks of Custom Software Compliance

Doctors and researchers often find themselves seeking the ability to gather data from multiple sources for analysis, but disconnected systems inhibit data transfer and limit or delay effective decision-making.

Custom applications are often developed to bridge disparate systems, but such code is often a compliance risk factor. In fact, systems integration – in most cases, the practice of bridging different vendor systems – is a key source of compliance issues. From a recent article at CIO (5 biggest IT compliance headaches and how to address them) 

“A major vulnerability of many companies comes from Electronic Data Interchanges (EDI) and vendor system integration. A 2017 report by Soha Systems indicated that as many as 63 percent of all reported data breaches originated directly or indirectly from third-party vendors… Managing not only vendor information security but also vendor compliance with privacy laws is a major undertaking and significant compliance challenge.”

From a security vulnerability standpoint, poorly-designed integration code and failure to address evolving security challenges are two particular concerns. Compliance with new & evolving regulations is another.

Different applications can mandate different approaches. Patient portal software integrations must be designed to address not only privacy (e.g., HIPAA and GDPR) compliance but also overall system security – on an ongoing basis. Modifications to clinical and production systems must address GAMP5 and 21 CFR Part 11 to ensure compliance with guidelines for temporary data, electronic signatures and audit trails.

There are also a number of 3rd party regulatory standards – some of which apply to the life sciences – that may require software/hardware compliance, including: PCI (Payment Cards Industry) security standards, GMPs, RESPA, HOEPA, FCRA and others.

Software development firms working in regulated industries must use coding methodologies which complement the applicable regulatory structures. More complex systems which process both clinical and personal data require greater software project planning and tighter control over sensitive data to ensure compliance with multiple regulations.

Ensuring Software Compliance & Security

Software developers typically use a number of methods to ensure compliance – whether from a regulatory or security standpoint.

Penetration (PEN) testing, or ‘ethical hacking,’ is a risk assessment procedure used to confirm the security of software by testing for vulnerabilities in systems, including APIs, operating systems and hardware (e.g., servers).

Permissions & Access Control are core security policies, often implemented as role-based-access-control (RBAC) in which the ability to perform certain operations is assigned to specific roles rather than individuals. Permissions should be vigorously managed and tracked, including detailed audit trails, with the goal of controlling & monitoring system and data access.

Change Control & Change Management
Any modifications to systems should be initiated through the use of well-managed and documented processes to reduce the likelihood of introducing system faults or disrupting activities.

Validating software to ensure compliance requires well-defined planning across the software development and deployment process. Test plans detail what tests will occur, who will conduct them, the specific testing tasks, the testing environment and more. The test plan also identifies risk factors & mitigating steps to be taken, if necessary. An audit plan, which focuses on software compliance rather than content, is typically conducted by teams independent of the software developer.

Custom software development typically follows a basic process:

  • Define the business, technical, visual, user experience and data integration requirements. 
  • Develop code & data structure, including stack selection, architecture, code control, continuous integration/continuous delivery (CI/CD) practices and database schema. 
  • Create documentation for the code, infrastructure and end user and/or administrators. Formal processes and documentation at each stage should demonstrate evidence of good process control. 
  • Put test and audit plans in place. 
  • Perform:
    1. Unit Testing
    2. Test Automation
    3. Review
    4. Feedback
    5. Integrate
    6. Acceptance Testing. 

In regulated industries in particular, there are additional software development considerations (though we consider them a good idea for all projects):

  • Reviewable audit trails. 
  • Standardized code (as much as possible).
  • The use of automation to replace as many manual tasks with auditable automated processes as possible.
  • Ensure the protection of both processes and data – including the use of robust encryption and disaster recovery plans.  

The Importance of Client-Vendor Collaboration

Given the high stakes in regulated environments, custom software development vendors should align their processes and documentation with customer needs. Customer acceptance – and ultimately approval – should be a collaborative process from start to finish.