Oracle Argus Safety and Adverse Event Reconciliation

Adverse Events / Adverse Drug Reactions are imperative to all interventional therapies, be it drugs, devices, vaccines or biologics. The frequency, seriousness, breadth etc. may vary from drug to drug, person to person. We have made a lot of progress in ensuring that all the adverse events are identified, processed and reported to regulators. However there are still a lot of challenges in ensuring consistency, of how this is done across organizations, in terms of people, process and technology.

Oracle’s Argus Safety Suite is a leading drug safety system in the market. It is a very good application with rich features. However, there are still certain functions, the industry needs, that needs to mature and some others that are still evolving. I would like to write about one such features i.e. Adverse Event Reconciliation. The module in Argus Suite that provides this functionality is “Argus Reconciliation”. The datasheet lists the benefits of reconciliation and the ability of this module to make it easy, to reconcile the AE data between Argus and other Clinical Data Management systems.

What is reconciliation?

Reconciliation is typically the process of identifying any discrepancies in the data captured for the Adverse Events in Clinical Data Management system and Safety System.

Why do they have similar data in two systems?

Adverse event data is captured in CDM systems as part of the clinical trial data collection process. This data is also entered in Safety Systems in order to capture, process and report it to regulators. Sponsors should ensure that the data that is submitted to regulators during the course of the trial and the data that is submitted as part of the overall submission are consistent. Hence, reconciliation of data is essential. Ideally this situation should not arise if the data is collected electronically and the systems are integrated so the information flows bi-directionally. However, that is not the case in real world.

For customers that have Argus Safety there are essentially three options for reconciliation:

1. Manual
2. Automated  (COTS) and
3. Automated (Custom)

Manual: This method, to a large extent is self-explanatory. One has to extract the AE records from the Safety and CDM systems and compare the data elements line item-by-line item. Any discrepancies identified may lead to a) change to the data in CDM system or b) change to the data in Safety system

Automated (COTS): This method can be used in case a commercially available integration exists between the CDM system and Argus. If we look at some of the popular CDM systems in the market, InForm (Oracle), Oracle Clinical and Rave (Medidata) two are from Oracle. The following information outlines the integration in case of each CDM system:

1)      In case of Oracle Clinical, the reconciliation is available through the Argus Reconciliation module. Customers have to buy licenses to this module as part of the Safety Suite in order to leverage this functionality.

2)      For Inform to Argus integration, Oracle has released a Process Integration Pack (PIP) that is part of their Application Integration Architecture (AIA), which in turn is part of their Fusion Middleware strategy. This essentially requires customers to install an AIA foundation pack and then purchase the PIP (Oracle® Health Sciences Adverse Event Integration Pack for Oracle Health Sciences InForm and Oracle Argus Safety) and install/configure it.

3)      Medidata Rave’s Safety Gateway product can be leveraged for integration between Rave and Argus Safety. This is basically an E2B based integration.

Automated (Custom): In cases where the volume of cases is very high, which eliminates the manual option, and a COTS integration does not exist, customers may have to rely on a custom integration. This can be accomplished in multiple ways. However, an E2B based integration is recommended.

Hope this post helps you get basic knowledge about AE reconciliation and options available for reconciliation between Argus Safety and three popular Clinical Data Management systems. As always, your feedback will be very valuable and welcome.

Leveraging Technology to Improve Patient Recruitment for Clinical Trials

I was asked to respond to a costumer inquiry recently to help them with providing a solution to improve their patient recruitment in clinical trials. Initially, I thought this must be a question to one of our experts in our CRO. However, I kept thinking about it and realized there isn’t a silver bullet that would solve this problem. There is no commercial off-the-shelf solution to fix this problem. Sponsors, CROs, Site Coordinators, PIs and other stakeholders involved in the clinical research have been struggling to address this situation but it is still a challenge and is the root cause of delays in clinical trials which will result in increased and lower Returns on Investment (ROI).

Discovery and development of medical products take a long time and consume lot of resources (Effort & Cost) from sponsors from molecule to patient. This involves discovery of the molecule to pre-clinical and clinical development to marketing & sales. A lot of these resources are typically spent in late stage (Phase III) of clinical trials. One of the root causes for delays in clinical trials in phase III is delay in recruiting the patients that meet the inclusion criteria of the protocol. Another key concern is patient drop out during the course of the trial. These issues not only delay the trial but also force the sponsors and CROs to consider changes to the protocol or force them to take alternative steps to ensure the necessary patient population is recruited to continue the trial.

Adherence rates across the duration of therapy

According to a report on Patient Adherence by Capgemini consulting [1], “Patient adherence levels vary between 50% for depression to 63% for enlarged prostate. On average, adherence levels drop over the course of the patient journey from 69% of patients filling their first prescription to 43% continuing their treatment as prescribed after 6 months.”

Also, if you notice in the attached diagram, 31% of the patients recruited will not last until they fill their prescription. Further, by the sixth month almost 57% patients do not show up for their refills. At this rate, in order to continue the trial, the sponsor has to continue to recruit patients during the course of the trial. This recruitment due to a drop out comes at a cost. The report has also identified that the cost of recruiting a new patient is 6 times the cost spent by sponsors to retain an existing patient.

So, what are the sponsors/CROs doing to improve the patient recruitment and reduce the drop outs? The key to fixing any problem is identifying the root cause. For this problem, there are multiple areas of failure and hence requires a comprehensive, multi-pronged strategy to fix the problems.  Some of the best practices being adopted by sponsors and/or CROs include:

• Comprehensive and incremental approach to integrated solutions rather than silos  by leveraging :

–          Patient registries

–          Better communication between patients and clinicians

–          Electronic records

–          Better engagement of physicians

• Refine Site selection

–          Analysis to select better performing sites

• Patient centric recruitment process

–          Simplify informed consent process (move to informed choice)

• Collaborative approach to Protocol design

–          Engaging Principal Investigators (PIs) in protocol design by research coordinators

• Improve patient retention

–          Better follow-up systems to increase adherence

–          Enhanced post-trial engagement

In order to implement these best practices sponsors can adopt technology solutions like:

1. Create strategy to improve the recruitment process by leveraging technology solutions
2. Analyze site performance and select high performing sites and drop out non-performing sites
3. Patient Recruitment Systems to search and match protocol eligibility criteria with patient’s available Electronic Health Records (EMRs, Narratives, Health Insurance and Claims Documents)
4. Social Media tools to target patient communities to identify potential subjects from the available patient population
5. Social Media tools to gauge trial buzz in patient and physician community
6. Study & Investigator Portals to enhance engagement and collaboration between study coordinators and Principal Investigators
7. Mobile Trial Adherence Systems to alert and notify patients of visits and other trial compliance activities to reduce drop outs
8. Key Opinion Leader portals to better engage physicians
9. Analytics to identify potential subjects, site initiation process and performance, patient recruitment effectiveness, patient drop out alerts etc.
10. Advanced analytics to simulate recruitment performance based on historical data and thus tailoring recruitment strategy based on sites and other factors

Despite all these best practices and solutions, will be able to help the sponsors and CROs in:

• Collecting historical and real time operational and scientific data
• Performing objective analysis of data
• Visualization of such performance
• Identifying the bottlenecks and root causes for the problems
• Helping in making decisions to select the right sites, recruit the right patients, avoid costly drop outs and improve the collaboration and communication among Patients, Primary Investigators and other stakeholders.

I will be writing about each solution in my “Top 10” list above. As I mentioned in the beginning of this post, there is no silver bullet for this problem. A strategic and integrated approach to create solutions that will aid in collecting, analyzing and decision making is the only way to solve this problem.

As always, please let me know your feedback. If you have more insights into the problem or solutions, I will be more than glad to discuss with you and also post some of the inferences in a subsequent post, as promised. Happy Reading!!!

References:

1. “Patient Adherence: The Next Frontier in Patient Care – Vision & Reality, 9th Edition Global Research Report”  by Capgemini Consulting

Can “Clinical Data Integration on the Cloud” be a reality?

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:

1. 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.)
2. 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.
3. 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:

1. Dell Boomi : Atom Sphere
2. Informatica : Informatica CLOUD
3. IBM : Cast Iron Cloud Integration
4. 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:

1. 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.
2. 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.
3. 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.
4. 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
5. 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.

Conclusion

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

Social Media, Literature Search, Sponsor Websites – A Safety Source Data Integration Approach

I haven been part of my fair share of discussions on Drug Safety and Social Media. In fact, I have even written a blog post about how these two are being forced into an “arranged marriage”, which could be a good thing :-). While processing data from social media is very complex and often unreliable, there is increased push to process it anyway. Understandably, Marketing teams are the first to adopt social media channels in pharmaceutical organizations, now the drug safety teams are being forced to act as these channels could end up generating adverse events and they are obligated to register, review and report.

As mentioned, processing of data from social media could be complex and may yield very few cases (0.2% according to a Nielsen’s Online survey of health-related social media content) the high level process is very similar to Literature Scanning. The later is something that is already being handled by organizations. I think that the Social Media content search and analysis can becoming an extension to this process. Now lets look at both the processes.

Literature Search:

Literature Search is used by BioPharmaceutical organizations to identify Adverse Events related to their medicinal products in medical and scientific journals published worldwide. This process was adopted as a result of multiple serious adverse events and the ensuing regulations and increased safety concerns. Many sponsor organizations have successfully built automated systems to speed up the overall process. These systems typically scan sources (Journals, Abstract Libraries and Reference Libraries) based on certain keywords, product names, Boolean expressions etc. and capture the mentions into a local database. These entries are then screened by trained professionals to either accept or reject them based on the required data elements to qualify as an adverse event. If additional details are required, the journals are purchased and reviewed to qualify the “hit” as an adverse event. Once identified, this becomes a case that will then be transferred manually or electronically (e.g. E2B) to an Adverse Event Management System and will follow the life cycle till it is reported as an expedited or periodic report to regulatory authorities.

Social Media:

This process can be very similar to Literature Search except that the source of data is much more diverse and also the data is far less structured. Depending on the source system, a manual or automated process can be adopted to monitor and record the “hits”. If the source system is a “blog” or “Twitter” or “Facebook”, a tool can be build to continuously poll certain blogs, tweets or Facebook pages to scan for keywords, products/brands etc. The resulting “hits” can be processed to filter and aggregate the “trends”. These trends can then be reviewed by trained professionals to make a decision on whether they qualify as “Safety Cases” that will then be processed per the AE case management process.

Enterprise Websites, Response Centers etc.:

The third variety that may be considered as source systems for safety cases are Brand Websites and other portals setup to increase the brand awareness or assist the patients to receive medicine faster or address any questions and concerns. This may even include response centers setup for patients, pharmacists and physicians to reach the sponsors for information and advice. Depending on the nature of inquiries, these could be potential sources of Adverse Events. This data, once screened and qualified, can also be fed into the AE Management System for subsequent review and reporting purposes.

Source Data Integration:

From a technology standpoint the architecture and design for aggregation and analysis of data may differ for each of the datasets. However, an integrated approach to collecting, aggregating, analyzing and reporting of Adverse Event data needs to adopted by the sponsor IT organizations. The diagram below depicts:

1. Multiple Source Categories and Systems (Literature, Social Media, Enterprise Websites)
2. Multiple Interfaces  (Manual, XML, Text, API, RSS, Web Services etc.)
3. Simple, High Level process to screen, record, review and report the case

Social Media Safety Source Data Integration

(To Be Continued…)

Clinical Information Super Highway and Integration

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.

Information Silos:

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).

Clinical Information Super Highway

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

Advantages:

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