In the last month at least 3 clients (top 10 Pharma) that I spoke to brought up Automation in the context of Regulatory Affairs. While it is very common for everyone to get excited about some of the popular technology trends and jump on the bandwagon to adopt these within a business context, many such initiatives fail to find traction and success unless they are carefully managed with a strategy and plan.
Regulatory Affairs function is not immune to this temptation. However, the excitement is typically tampered by the implications of things not working out resulting in regulatory compliance issues and product approvals. However, many activities within Regulatory Operations are repetitive in nature and are very conducive to being considered for automation. In my opinion, the criteria that should be considered while assessing a business process for automation are:
- Process Type: Nature of the Business Process in terms of Strategic vs. Tactical
- Frequency: How frequently is the process invoked to deliver business value
- Manual Tasks: How many tasks within a process are manual in nature and are leading to process inefficiencies and errors
- Benefit: How much hard/soft benefit can be delivered by automating the tasks
- Performance: Can the steps be measured easily to assess the performance
Assessment & Prioritization:
To create a strategic plan for automation, each process in Regulatory Affairs ranging from Regulatory Strategy to Life Cycle Maintenance can be assessed based on these criteria.
Prioritization of the processes and/or tasks within a process can be done by arriving at a balanced scorecard for automation. The weightages provided in the chart can be used as reference but can always be tailored based on any given organizations’ needs and inputs. The criteria can also be leveraged at the enterprise level to assess other functional areas like Clinical and Safety, in order to prioritize at the department level to assign and approve budgets. The key is a structured way of identifying opportunities, assessing them for automation ability and prioritizing based on balanced scorecard.
The above score card does not cover all the processes of the Regulatory Affairs processes. However, it is used to illustrate how to create a balanced score card to prioritize the processes for automation.
While organizations are considering moving to a Regulatory Information Management platform of the future, they can still consider automation as a way to compliment process improvements achieved. In fact, I strongly recommend creating an ‘Automation’ workstream as part of the RIM initiative so that all the work done to harmonize the processes and transform the processes in preparation for new platform adoption can be harnessed to assess and prioritize the processes for automation with minimal impact to ongoing work.
In a subsequent post, I will look at the processes within Regulatory Affairs that can be prioritized over others, based on my experience. I will also look at potential use cases within each process.
Apple has sold millions of iPads in the past 18 months. The adoption of the device in the market is phenomenal. This trend is reflected in Life Sciences & Healthcare industry as well. A mobile Health News article (2012: About 62 percent of physicians use tablets) puts the adoption of tablets by the physicians at 62%. Another report by IDC puts the Smart Devices sales exceeding the combined sales of laptops and desktops. All these trends are indicative of the rate of adoption of mobile and smart devices by the population in general. The healthcare and life sciences industries are no exception to this.
While the adoption is growing in general, the challenges and bottlenecks are numerous for adoption of the devices in an Enterprise/Business setting. To make this even more complex, consider using the tablets and smart phones in a validated environment to capture and manage personal health information of patients.
Some key questions to be asked while considering adoption of Mobile devices in a validated environment are:
- Will the device and application be considered a Mobile Medical Device?
- If so, what should we do to validate the application?
- What are the regulatory requirements and guidance from the agencies?
- Should we consider a native application vs. a web based application?
- If so, how does the validation activities and artifacts differ?
- Would the data be stored on the device or would it be transferred to the server as soon as it is captured?
- Should we make it available offline to enable usage without internet connectivity?
- What are the synchronization challenges?
- How do we handle identity management?
- How do we ensure data security?
While some of these questions are applicable to any enterprise mobile application, they are even more important to consider if the Mobile device is slated to be used in a regulated environment. For customers in the US, one key document to be considered as input, to answer some of the questions, is FDA’s DRAFT Guidance for Mobile Medical Applications.
mHIMSS Policy & Regulatory Implications Workgroup has provided a very good summary of how the guidance should be interpreted with respect to Mobile Medical Applications. You can read the summary here (needs registration).
FDA also provides more useful information on Mobile Medical Applications here.
I look forward to comments and insights into any specific experiences that you might have had with respect to developing Enterprise Mobile Applications in a regulated environment. These applications may or may not be companion applications to devices, but may fall under the MMA purview as defined in the guidance.
The story I am about to tell is almost 8 years old. I was managing software services delivery for a global pharmaceutical company from India. This was a very strategic account and the breadth of services covered diverse systems and geographies. It is very common that staff from the customer organization visit our delivery centers (offsite locations) to perform process audits, governance reviews and to meet people in their extended organizations.
During one such visit a senior executive noticed that two of my colleagues, sitting next to each other, supported their system (two different implementations of the same software) across two different geographies. They happened to have the name of the systems they support, pinned to a board at their desks. The executive wanted us to take a picture of the two cubicles and email to him. We were quite surprised at the request. Before moving on to speak to other people he asked a couple of questions and realized the guys were sharing each other’s experiences and leveraging the lessons learnt from one deployment for the other geography. It turned out that this does not happen in their organization, in fact their internal teams hardly communicate as they are part of different business units and geographies.
The story demonstrates how these organizations could become siloes due to distributed, outsourced and localized teams. Information Integration has become the way of life to connect numerous silos that are created in the process. Clinical research is a complex world. While the players are limited, depending on the size of the organization and the distributed nature of the teams (including third parties), information silos and with that the complexity of integration of data increases. The result is very long cycle times from data “Capture” to “Submission”.
Clinical Data Integration Challenges
The challenges in integrating the clinical data sources are many. I will try to highlight some of the key ones here:
- Study Data is Unique: depending on the complexity of the protocol, the design of the study, the data collected varies. This makes it difficult to create a standardized integration of data coming in from multiple sources.
- Semantic Context: while the data collected could be similar, unless the context is understood, it is very hard to integrate the data, meaningfully. Hence, the integration process becomes complex as the semantics become a major part of the integration process.
- Regulations and Compliance: Given the risks associated with clinical research, it is assumed that every phase of the data life should be auditable. This makes it very difficult to manage some of the integrations as it may involve complex transformations along the way.
- Disparate Systems: IT systems used by sponsors, CROs and other parties could be different. This calls for extensive integration exercise, leading to large projects and in turn huge budgets.
- Diverse Systems: IT systems used at each phase of the clinical data life cycle are different. This makes sense as the systems are usually meant to fulfill a specific business need. Even the functional organizations within a business unit will be organized to focus on a specific area of expertise. More often than not, these systems could be a combination of home grown and commercial off the shelf products from multiple vendors. Hence, the complexity of integrations increases.
What is Integration on the Cloud?
As mentioned earlier, integration is a complex process. As the cloud adoption increases, the data may be distributed across Public, Private (Includes On-Premise applications) and Hybrid clouds. The primary objective of integration on the cloud is to provide a software-as-a-service on the cloud to integrate diverse systems. This follows the same pattern as any other cloud services and delivers similar set of benefits as other cloud offerings.
The “Integration on Cloud” vendors typically offer three types of services:
- Out-of-Box Integrations: The vendor has pre-built some point-to-point integrations between some of the most used enterprise software systems in the market (like ERPs, CRMS etc.)
- Do-it-Yourself: The users have the freedom to design, build and operate their own integration process and orchestrations. The service provider may provide some professional services to support the users during the process.
- Managed Services: the vendor provides end-to-end development and support services
From a system design and architecture perspective, the vendors typically provide a web application to define the integration touch points and orchestrate the workflow that mimics a typical Extract-Transform-Load (ETL) process. It will have all the necessary plumbing required to ensure that the process defined is successfully executed.
Who are the players?
I thought it would be useful to look at some of the early movers in this space. The following is a list (not exhaustive and in no particular order, of course) of “Integration on Cloud” providers:
- Dell Boomi : Atom Sphere
- Informatica : Informatica CLOUD
- IBM : Cast Iron Cloud Integration
- Jitterbit : Enterprise Cloud Edition
These vendors have specific solution and service offerings. Most of them provide some out-of-the-box point-to-point integration of enterprise applications like ERPs, CRMs etc. They also offer custom integrations to accomplish data migration, data synchronization, data replication etc. One key aspect to look for is “Standards based Integration”. I will explain why that is important from a clinical data integration perspective later. While this offering is still in its infancy, there are some customers that use these services and some that are in the process of setting up some more.
Clinical Data Integration on Cloud
Many of you dealing with Clinical Data Integration may be wondering as to “Why bother with Integration on the Cloud?” while we have enough troubles in finding a viable solution in a much simpler environment. I have been either trying to create solutions and services to meet this requirement or trying to sell partner solutions to meet this requirement for the past 4 years. I will confess that it has been a challenge, not just for me but for the customers too. There are many reasons like, need to streamline the Clinical Data Life Cycle, Data Management Processes, retiring existing systems, bringing in new systems, organizational change etc. Not to mention the cost associated with it.
So, why do we need integration on the cloud? I firmly believe that if a solution provides the features and benefits listed below, the customers will be more than willing to give it a strong consideration (“If you build it, they will come”). As with all useful ideas in the past, this too will be adopted. So, what are the features that would make Clinical Data Integration on the cloud palatable? The following are a few, but key ones:
- Configurable: Uniqueness of the studies makes every new data set coming in from partners unique. The semantics is also one of the key to integration. Hence, a system that makes it easier to configure the integrations, for literally every study, will be required.
- Standards: The key to solving integration problems (across systems or organizations), is reliance on standards. The standards proposed, and widely accepted by the industry (by bodies like CDISC, HL7 etc.) will reduce the complexity. Hence, the messaging across the touch points for integration on the cloud should rely heavily on standards.
- Regulatory Compliance and GCP: As highlighted earlier, Clinical Research is a highly regulated environment. Hence, compliance with regulations like 21 CFR Part 11 as well as adherence to Good Clinical Practices is a mandatory requirement.
- Authentication and Information Security: This would be one of key concerns from all the parties involved. Any compromise on this would not only mean loss of billions of dollars but also adverse impact on patients that could potentially benefit from the product being developed. Even PII data could be compromised, which will not be unacceptable
- Cost: Given the economically lean period for the pharma industry due to patent expiries and macro-economic situation, this would be a key factor in the decision making process. While the cloud service will inherently convert CapEx to OpEx and thus makes it more predictable, there will be pressure to keep the costs low for add-on services like “new study data” integration.
All in all, I would say that it is possible, technically and economically and also a step in the right direction to overcome some existing challenges. Will it happen tomorrow or in the next 1 year? My answer would be NO. In 2 to 3 years, probably YES. The key to making it happen is to try it on the cloud rather than on-premise. Some of the vendors offering Integration on Cloud could be made partners and solve this age old problem.
Update on 03/27/2012:
This post has been picked up by “Applied Clinical Trials Online” Magazine and posted on their blog -> here
Generic Industry Challenges:
Expiring patents, drying pipelines, increasing budgets, stringent regulations and cost pressures are some of the challenges faced by the Life Sciences industry. While these are macro challenges, teams responsible for clinical, regulatory and safety for clinical trials, regulatory submissions and patient safety respectively have a totally different set of challenges that they deal on a regular basis.
Data and documents generated during the course of the trials are managed by IT systems that have been either built in house or procured off the shelf. A major challenge that is faced by IT teams in large enterprises is to provide information and intelligence to their business teams that would cross (by integrating information) these siloes and help them make sound business decisions.
SOA based Information Integration:
Imagine a situation where all these systems in the clinical enterprise are integrated and connect seamlessly. The glue that binds all these systems can be a fully Service Oriented Enterprise Service Bus (ESB). Not just that, it should also be standards based. This will reduce the dependency on interfaces between systems in use and future proof the enterprise from replacement, retirement and enhancements to the individual systems. In order to bring visibility to data and documents across the systems there is a need to aggregate data and documents into Clinical Data Repository (CDR) and an Enterprise Electronic Document Management System (EEDMS).
The diagram above depicts a few information systems within the Clinical, Regulatory and Safety areas of Life Sciences R&D. This integration has to be:
- Loosely Coupled (SOA)
- Standards Based (CDISC / HL7)
- Open Architecture (XML, SOAP) and
- Survive system upgrades, replacements and retirements
Some of the advantages with the above mentioned integration would be:
- Integrated Clinical Enterprise Information Systems
- Easier and simpler integrations with partners and third parties
- Adoption of standards
- Integrated data and documents to enable faster decision making
- Faster Time to Market
- Lower Total Cost of Ownership and
- Better ROI