Electronic data collection and submission of Adverse Events (AEs) in recent years has enabled organizations to collect huge data sets of safety information. Some pharmaceutical organizations have invested heavily on building or procuring IT systems that can analyze these datasets and produce safety observations that have the potential to become signals. This method of applying mathematical / scientific statistical algorithms to identify potential signals is termed as ‘Quantitative Signal Detection’. Another way of identifying safety observations is the manual process of reviewing all cases being reported, by a medical professional, to identify potential signals. This process is termed as ‘Qualitative Signal Detection’. Many small to medium organizations employ this method of detecting potential signals. More than the size, it is the volume of cases that need to be analyzed that would be a key criterion for organizations leaning one way or the other. Some organizations may also employ a hybrid model i.e. quantitative analysis followed by qualitative analysis.

Microsoft SharePoint is a very popular collaboration and content management platform adopted by many organizations across the globe. Life Sciences organizations are no exception to this trend. In recent years SharePoint has seen rapid growth in even areas that require more cautious adoption of new technology due to the impending regulatory requirements (e.g. 21 CFR Part 11 compliance). However, due to the efforts from Microsoft as well as other IT and Life Sciences organizations SharePoint is being adopted in areas where it requires validation.

Signal Management, the process that ensues once the Signals are detected using one of the two methods i.e. Qualitative or Quantitative Signal Detection, is the process where the information related to a safety observation and the corresponding cases that lead to the observation are reviewed by professionals and scientists and decision is made on whether the signal is refuted or verified (other states are also possible).  The information is usually captured in forms and passes on from one state to another following a specific workflow with associated service levels for each step in the process. This yields itself as a potential candidate for automation. SharePoint natively supports configuration of forms, management of documents as well as simple workflows. As mentioned above, many organizations have already made investments in SharePoint and hence will be able to save costs by leveraging this tool for Signal Management automation.

1.       Customization Vs Configuration

SharePoint, implemented as a Document Management System would provide the ability to store and retrieve documents along with other features like version control etc. However, in order to leverage it for regulatory document management a lot of customization is required in terms of workflow, terminology, metadata, reports etc. In contrast a COTS system comes with flexible, predefined workflow and other features required for regulatory document management system of a Life Sciences organization’s requirement.

2.       Rapid Implementation

Traditional SharePoint roll-out may take months to implement and configure it for regulatory requirements like 21 CFR Part 11, Electronic/Digital Signatures etc. On top of that, customization of SharePoint is required to adopt it for regulatory document management. A COTS system implementation is typically completed much faster including validation of the system to comply with regulatory requirements such as 21 CFR part 11.

3.     Electronic Signatures, Audit Trail and 21 CFR Part 11 compliance:

Most COTS systems are available with e-signatures that are required as part of 21 CFR Part 11 compliance. A regular SharePoint implementation demands additional effort to be spent to configure this feature such that it is applicable to regulatory document management. The COTS systems also provide audit trail feature which is then leveraged in reporting and assists in audit process.

4.       Metadata and Terminology

Meaningful metadata is the key to be able to search and retrieve documents easily. Also, the metadata needs to have fields that are domain specific rather than generic. Traditional SharePoint implementation does not define the metadata required to store regulatory documents whereas most COTS Regulated DMS’ come with predefined metadata for regulatory document management and also has provision to configure these based on organizational requirements.

5.       Reports and Audit

Most COTS systems provides reporting capability out of the box. However, these reports are not available in standard SharePoint implementation.

While Cost, Vendor Dependency etc. could be reasons why customers might want to use SharePoint out-of-the-box with some configuration, it will never be the same as a purposefully  designed and developed commercial system. As always, feedback and comments are welcome.

In the US, the Federal Drug Administration (FDA) has been trying to address this through various regulations for over five years through Risk Management Action Plans (RiskMAP) and Risk Evaluation and Mitigation Strategies (REMS). The most recent guidance on this subject was issued in September 2009 through “Guidance for Industry Format and Content of Proposed Risk Evaluation and Mitigation Strategies (REMS), REMS Assessments, and Proposed REMS Modifications”. In this guidance one of the important REMS elements that may be required is “Elements to Assure Safe Use”.

As part of this requirement the NDA/BLA applicants have to take measures to provide safe access for patients to drugs with known serious risks that would otherwise be unavailable. If a product is assessed to fulfill ETASU requirements then the sponsors are required to train and certify health care providers, pharmacies, patients and drugs. The drugs may be released to patients in a controlled manner only upon receiving evidence of their lab results. The sponsors may also have to register the patients and might subject them to certain monitoring as well. In a few cases the sponsor may be asked to extend the certification process to wholesalers, distributers etc. as well.

In order to fulfill the above mentioned requirements sponsors typically set out to build new IT systems. This is a challenging task as there is a possibility that these requirements could change over time and also there aren’t any commercial off the shelf products available in the market to address the specific REMS ETASU requirements.

To overcome this challenge, sponsors can look up to a Business Process Management System (BPMS) that is precisely built to handle such scenarios. Many other industries have successfully used BPMS to meet their ever changing requirements and priorities by integrating their business processes based on rules. Many commercially available BPMS systems typically include a process engine, Business Analytics, Content Management and Collaboration tools. These BPMS system building blocks can be effectively leveraged to fulfill the ETASU requirements by effectively providing features like Rules management, Content Management, Training Management, Patient/Provider/Pharmacy Registries, Collaboration Portal/Website, IVR/IWR, 21 CFR Part 11 compliance, Audits and integration with other enterprise applications.

Update: 01-17-2012

My Article on the same topic is published on “Drug Safety Directions” Website. You can access the article here: “Implementing FDA REMS Elements to Assure Safe Use (ETASU) Requirements using a Business Process Management Suite“.

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

The reason I started down this path was a presentation I had to do at work this morning. We have been partnering with a vendor for over the last couple of years and have made some investments in the partnership in terms of money, time and resources. There was a point where we thought it probably isn’t getting us enough benefits to continue to invest in this partnership anymore. However, we wanted to take a pragmatic approach to this. So, we thought let’s review where we are, identify ways to make it work and despite these efforts if it doesn’t, then we can call it quits.

Just like I tried with my title for this post, I think it is key to set the right expectations when it comes to partnerships and alliances. While I do not want to get into the technicalities of partnerships, alliances and other such relationships and their nature, I thought I’d put down a list of things that would deliver value from relationships:

Value : There should be value that both the partners are bringing to the table. Be it investment, Experience, Resources or in any other form.

Benefits: There should be mutual benefits out of the relationships. As many of us might have experienced, irrespective of how binding the contract for the partnership would be, it just would not work if either party realizes there isn’t enough for them in that relationship.

Trust: Both the parties should trust each other and believe that the other party is working towards a mutual benefit and not its own.

Time: Both parties need to give the relationship some time to mature and start yielding results. Just because you signed a piece of paper or paid a fee doesn’t make you both tick instantaneously. Underneath all of it is people who are interacting and collaborating with people and while I am no expert at commenting on human relationships, I can definitely say that it takes time for those to mature.

There could be multiple other factors that would influence a partnership, but I thought these are the four fundamental pillars on which partnerships should be built on so they can flourish. While every partnership may not start with all these four aspects covered in equal parts, but I am confident that they will flourish once they all strike a balance in the relationship.

While the title is “Why do you need a partner in business?”, which I think might be obvious for most of you, I thought it is important to highlight what makes these partnerships tick.

As always, your feedback and comments are welcome.