Pega Pharmacovigilance - Product Overview

Pega Pharmacovigilance

PRODUCT OVERVIEW 7.31

© 2017 Pegasystems Inc., Cambridge, MA

All rights reserved.

Trademarks

For Pegasystems Inc. trademarks and registered trademarks, all rights reserved. All other trademarks or service marks are property of their respective holders.

For information about the third-party software that is delivered with the product, refer to the third-party license file on your installation media that is specific to your release.

Notices

This publication describes and/or represents products and services of Pegasystems Inc. It may contain trade secrets and proprietary information that are protected by various federal, state, and international laws, and distributed under licenses restricting their use, copying, modification, distribution, or transmittal in any form without prior written authorization of Pegasystems Inc.

This publication is current as of the date of publication only. Changes to the publication may be made from time to time at the discretion of Pegasystems Inc. This publication remains the property of Pegasystems Inc. and must be returned to it upon request. This publication does not imply any commitment to offer or deliver the products or services described herein.

This publication may include references to Pegasystems Inc. product features that have not been licensed by you or your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems Inc. services consultant.

Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors, as well as technical inaccuracies. Pegasystems Inc. shall not be liable for technical or editorial errors or omissions contained herein. Pegasystems Inc. may make improvements and/or changes to the publication at any time without notice.

Any references in this publication to non-Pegasystems websites are provided for convenience only and do not serve as an endorsement of these websites. The materials at these websites are not part of the material for Pegasystems products, and use of those websites is at your own risk.

Information concerning non-Pegasystems products was obtained from the suppliers of those products, their publications, or other publicly available sources. Address questions about non-Pegasystems products to the suppliers of those products.

This publication may contain examples used in daily business operations that include the names of people, companies, products, and other third-party publications. Such examples are fictitious and any similarity to the names or other data used by an actual business enterprise or individual is coincidental.

This information is the property of:

Pegasystems Inc. One Rogers Street Cambridge, MA 02142-1209 USA Phone: (617) 374-9600 Fax: (617) 374-9620 www.pega.com

Pega Pharmacovigilance

Document: Product Overview

Software Version: 7.31

Updated: July 2017

CONTENTS

Product overview ................................................................................................ 1

Pega PV modules ................................................................................................ 1

Pega PV inbound ................................................................................................. 2 Typical configuration ....................................................................................... 2 Typical workflow .............................................................................................. 3 Administrative functions .................................................................................. 5

Product configuration ................................................................................ 6 Product labeledness .................................................................................. 7

Pega PV outbound .............................................................................................. 8 Typical configuration ....................................................................................... 8 Typical workflow .............................................................................................. 9 Typical integrations ....................................................................................... 11 Standard report submissions ......................................................................... 13

XML reports ............................................................................................. 13 PDF forms and reports ............................................................................ 13

Administrative functions ................................................................................ 14 Managing destinations ............................................................................ 15 Managing product mappings ................................................................... 17 External product data .............................................................................. 18 Adjusting the SLA clock date ................................................................... 19 Modifying a parent case SLA .................................................................. 19

Distributing submissions to external parties .................................................. 20

Pega Pharmacovigilance Exchange (PVX) ..................................................... 22 Typical PVA workflow .................................................................................... 22

Creating an agreement ............................................................................ 22 Defining timeline for different stages ....................................................... 24 Defining responsibilities ........................................................................... 25 Performing periodic reviews .................................................................... 26 Creating an agreement revision .............................................................. 27 Searching PVA. ....................................................................................... 28 Monitoring tasks ...................................................................................... 28

Administrative functions ................................................................................ 29

Data model ......................................................................................................... 31 Sample data .................................................................................................. 31

Roles, access groups and portals ................................................................... 32

Visit the Pega Discovery Network (PDN) ...................................................... 33 Visit the Mesh page ....................................................................................... 33

Appendix A: Pega PV – Capturing case data with screenshots ................... 34

Pega Pharmacovigilance - Product Overview 1

The Pega® Pharmacovigilance (Pega PV) application manages a wide range of Pharmacovigilance (PV) processes by supporting PV processes, data models, business rules, forms and templates, case structures, and user interfaces built on the Pega Platform 7.3. The Pega Platform and the Pega PV application help global life sciences companies reduce both cost and risk. Pega PV leverages the Pega Platform and the Pega Foundation for Life Sciences (PFLS) to provide core business process, business rules, case management, auditability, and integration with conventional safety systems.

The following are the main features of Pega PV.

Operational efficiency — significantly reduces per-case processing costs across process areas to support growth and cost reduction mandates.

Reduce risk — de-risks both large scale and acquisition-driven safety system migrations with a Pega business layer. Facilitates global risk management processes.

Build for Change — simplifies and speeds regulatory and business rules changes, and enables specialized global requirements around process and privacy.

This document provides an overview of the following for each Pega PV module:

Configuration and workflow

Administrative functions

Integrations

Product overview


The Pega PV application uses a modularized architecture to enable targeted and incremental implementations. It includes and inbound module and an outbound module. You can use these modules individually, together, or in conjunction with other Pega solutions such as Pega Customer Engagement for Life Sciences (CELS).

You can deploy the inbound and outbound components of Pega PV in various configurations. The following are the configurations which are described later in this document.

Inbound only — where Adverse Events (AE)/Product Complaints (PCs) are captured with Pega PV inbound and then passed to a separate safety system (for example, AERS) for additional processing.

Outbound only — where Pega PV receives or extracts cases from a separate safety system for report generation (for example, PDF/E2B), distribution, review, and submission.

Both inbound and outbound with a safety system — used with a separate safety system, performing case intake with Pega PV, passing cases to a safety system for case processing, then passing cases from the safety system to Pega PV Outbound for reporting and distribution.

Inbound and outbound without a safety system — performs all case processing activities in Pega PV, captures case data with Pega PV Inbound, performs additional case processing and review in Pega PV and Pega Platform, then passes cases to Pega PV Outbound for reporting and distribution.

Pega PV also includes the Pharmacovigilance Exchange (PVX) module that manages the creation, approval, and tasks for Pharmacovigilance Agreements (PVAs) between organizations.

Pega PV modules


The Pega PV inbound Module provides data capture for Adverse Events (AEs) and Product Complaints (PCs). It includes easily configurable user interfaces for combined AE and PC Intake, interactive UI — responsive data capture screens for Reporter, Subject (medical history, drug history, and parent details), lab reports, medical products (drug and devices), AE, PC, questionnaires, and other E2B industry standard fields. The following are the features of the Pega PV inbound module.

Manages different case types — easily identify and create new or follow-up cases.

Automatic case routing — automatic case routing to Medical Review Specialist (MRS)/Quality Review Specialist (QRS) to improve quality by identifying potential errors and correcting the data.

Product search and selection UI — Leverages Pega Foundation for Life Sciences (PFLS). PFLS supports an Identification of Medicinal Products (IDMP) harmonized data model. This data model allows companies to search products using standardized data fields such as Nation Drug Codes (NDC) and Unique Identifier (UNII) Substance information.

Prevents duplicate entries — duplicate check support to improve data quality and reduce manual interventions. Allows Intake user to preview existing cases and take appropriate action.

Manages AE/PC questionnaires — leverages Survey Management tool to create/update AE, PC as well as product specific questionnaires which can adapt on-the-fly to user input.

Bulk edit Event cases — the bulk edit feature allows you update multiple cases in a single batch mode. The case audit history tables preserve the complete audit history.

Integration capabilities.

− Integrate with external sources to retrieve Subject, Reporter and Product details.

− Create cases from Email/Fax/Image, Electronic Data Capture (EDC) (XML, Web Services, or Java API).

− Integrate with Pega Customer Engagement for LS application. See the Pega Customer Engagement for Life Sciences 7.22 implementation guide for more details.

Full audit trail capabilities — leverages Pega Foundation for Life Sciences (PFLS) to configure full design-time and run-time audit trails. See the Pega Foundation for Life Sciences 7.31 implementation guide for more information.

Reporting capabilities — take advantage of several Pega-provided reports that provide data on different business processes using report browser interface. Authorized end users can create, review, modify, and export the reports.

Typical configuration Pega PV Inbound provides comprehensive data capture for AEs and PCs, and the ability to send case data to safety systems or Pega PV Outbound for continued processing. You can run Pega PV Inbound as a stand-alone Pega application, or embed it within CELS. A typical environment may include:

Pega PV inbound


TITLE of INTERNAL DOCUMENT – Arial Bold 12

Safety Systems –– one or more safety systems, such as AERS, Argus, and ArisGlobal that are used to record and evaluate safety information. You can configure Pega PV Inbound to send cases to safety systems through a variety of mechanisms, including: relational database connectors, web services, and file transfer (for example, E2B XML files). Pega PV Inbound can distribute AEs and PCs to multiple safety systems through different channels, based on business rules.

Document Management System/Repository –– you can use a repository or a file system as a source for new cases (FAX or scanned documents). You can configure Pega PV to create cases from a specific folder or repository locations.

Master Data –– Pega PV includes sample tables for products, reporters, and subjects. You can replace this by direct integration to existing data sources and systems.

Authentication and Access Control –– Pega PV uses standard Pega authentication and access control components and may be integrated with existing infrastructure and systems.

FAX, Email, EDC –– you can create cases in Pega PV through data entry, or trigger them by external sources. FAX and email can automatically trigger creation of new cases and you can use structured data from systems such as EDC to create and populate new cases automatically.

Pega PV Outbound –– Pega PV Inbound can integrate with and transfer cases directly to Pega PV Outbound.

Pega CS/CELS –– you can embed Pega PV Inbound within Pega Customer Service (CS), including Customer Engagement for Life Sciences (CELS). AE/Product Complaint capture can occur within CELS. Pega CELS adds comprehensive multi-channel capabilities including telephony, FAX, chat, social media, and correspondence.

Typical workflow A basic implementation consists of the following steps:

Log in to the Pega PV portal or other environment, for example, Pega Customer Service application, or a web browser using Internet Application Composer (IAC).

Enter case data into screens in Pega PV.

Enter data for adverse events and product complaints.



After you create a case, you need to enter information or review and confirm existing case data. Depending on the nature of the case, a screen with collapsible layouts appears for you to quickly update and review the changes:

Some information is pre-populated. You can configure the system to let users override this data or present it as read-only.

Common data entry helpers include date lookups, lists of values, or auto-complete fields that suggest answers as you type.

Some fields use conditional display logic – for example, if you select that the subject was hospitalized, additional fields appear that request more information.

The system captures Complaints and Adverse Events, and the data capture process adjusts automatically to the nature of the product issue.

You can add metadata, notes, and tags, as well as drag-and-drop attachments, and collaborate with other participants for any case.



Workflow example: 1. From the New menu in the Pega PV portal, select Product Issue Intake.

2. Enter basic case details, reporter, and subject information.

You can enter data for these sections manually, or populate them automatically from external data sources. For example, if the system is integrated with email, you can configure it to automatically suggest a reporter by looking up the email address in the CRM database, and populating the reporter data automatically.

3. Enter the products involved, by searching them in Internal Product or WHO Drug Dictionary table. You can also add new product if the product doesn’t yet exist in both the tables. You can configure a newly added product to add it to the internal product table.

4. Classify them as Suspect AE (AE), Suspect Concomitant, Product Complaint (PC), or Combination AE/PC.

5. For PCs or Combination AE/PCs, enter information about the complaint, and select actions to resolve it, such as refund or replace.

6. For AEs or Combination AE/PCs, enter information about the AE – Medical Dictionary for Regulatory Activities (MedDRA) codes––if required––and lab results (including additional attachments).

7. For AEs or Combination AE/PCs, specify causality or relatedness for the suspect products.

8. For AEs or Combination AE/PCs, complete the AE questionnaire with information about seriousness, hospitalization, drug allergies, treatment received, de-challenge or re-challenge, and outcome.

− The system recommends the disposition of the case (serious, expected, and so on), and if this conditions are met then the system routes the case to Medical Review Specialist (MRS) for review. The MRS can make necessary adjustments, if necessary.

− Pega PV then sends the case data, using XML, E2B, or other structured data format to a safety system, for example, Oracle Argus, or to Pega PV Outbound for report generation, affiliate review, and submission.

Administrative functions Pega PV Inbound includes a default Administrator role (PegaPVAdmin) that can view all cases, tasks, and reports in the system. As an Inbound admin you can view the admin functionalities by clicking on the Admin link in left panel.



The following tabs are available under Admin:

Product configuration

Product labeledness

Product reporting

Product configuration As an admin you can manage different product specific configurations. The system leverages product specific configurations in different stages of the Inbound Intake process. From Product configuration you can:

Add a new product configuration row.

Determine product labeledness automatically.

Set a product configuration to Active or Inactive.



Product labeledness As an admin you can manage product labeledness decisions. By default Pega PV displays only the products that you configured in Product Configuration, but you can configure to display all products. From the Product labeledness tab, you can:

Specify the known MedDRA codes for the given product by clicking the Add MedDRA Codes link.

Search for the MedDRA code or select the MedDRA code directly from a list.

Save known adverse events to the database.

Note: Whenever a user selects a different MedDRA code other than known MedDRA codes defined in product labeledness table, Pega PV is configured to route the case automatically to Medical Review Specialist (MRS) before routing the case to Outbound Reporting stage. Such risk verification helps ensure the quality and accuracy of data is maintained properly.

The system can also use other factors like fatality, hospitalization to determine if the case needs medical specialist attention. You can change the risk factors and the logic that routes the case automatically to MRS just like any other element in the process.


The Pega PV Outbound Module automates the global distribution of safety reports and submissions to affiliates, business partners, regulators, and other interested parties. Pega PV Outbound provides the following functionality:

Manage global reporting business rules — create and manage Foreign/Local reporting rules for various destination types.

Integration capabilities:

− Receive cases directly from Pega PV Inbound module.

− Integrate with directory/access control systems.

− Integrate with safety systems using XML (E2B), web service, database, or other interfaces.

Life sciences reporting capabilities:

− E2B (M) / (R3) (XML)

− MedWatch (PDF)

− eMDR (XML)

− CIOMS (PDF)

Distribution capabilities:

− Distribute case details as well as reports to affiliates/business partners based on country or region for review and update.

− Distribute reports to regulatory agencies.

Support for auto approval — Pega PV can automatically approve cases based on the auto-approve rules defined by the safety admin.

Full audit trail capability — leverage Pega Foundation for Life Sciences (PFLS) to configure full design-time and run-time audit trails (See the Pega Foundation for Life Sciences 7.31 implementation guide for more information).

Modify Parent Case/Subcase SLA — safety Admins and authorized affiliates can modify SLA’s for both Adverse Event Cases and subcases sent for affiliate/partner reviews.

Typical configuration Pega PV Outbound listens through a variety of channels for new safety cases and manages their distribution across affiliates, business partners, and other recipients. A typical environment involves the following elements:

Safety Systems –– one or more safety systems, such as AERS, Argus, and ArisG that record and evaluate safety information. You can configure Pega PV Outbound to monitor safety systems and gather completed cases through a variety of mechanisms, including: relational database triggers, web services, and file listener (for example, E2B XML files).

Pega PV outbound



Multiple safety systems may feed into Pega PV Outbound through different channels to manage distribution of cases centrally.

Document Management System/Repository – you can use a repository or file system as a destination for outgoing submissions and reports. You can configure Pega PV to deliver submissions to specific folder and repository locations for automated pickup by submissions management systems.

Product Master – Pega PV includes a global product master. You can replace this by direct integration to a global product registration system, populate manually, or automatically by product registration data.

Authentication and Access Control – Pega PV uses standard Pega authentication and access control components. You can integrate Pega PV with your existing infrastructure and systems. In a typical Pega PV Outbound environment, Pega access, and permissions manage –– which affiliate users have access to which countries and destinations. Depending on configuration, a single user may have simultaneous access to affiliate work queues for multiple destinations. For example, while the system maintains individual work queues for each country in Europe, a single user may simultaneously manage outbound cases for UK, France, and Germany.

Pega PV Inbound – Pega PV Outbound can receive cases directly from Pega PV Inbound or cases that originated in Pega PV Inbound that are subsequently transferred to an intermediary safety system.

Typical workflow The following is the typical Pega PV outbound workflow:

When running in a typical deployment, a case starts in the safety system or in Pega PV Inbound.

When the case reaches completed status, Pega PV either sends the case data directly, or retrieves from the safety system directly to create a new Global Case.

This Global Case is evaluated by Pega PV to determine, based on global product registration data, the possible set of destinations for reporting and submissions.

Pega PV then evaluates the Global Case data against business rules that control reporting requirements for each possible destination.

For each instance where the Global Case data matches a reportable condition, Pega PV creates a new local subcase.

Each local subcase is a subcase of the Global Case.

For each local subcase created, the system further determines whether it should be distributed to an affiliate, a user with direct access to the Pega PV system or a business partner, a user who is only able to receive one-way distributions (email by default).

Finally, for each affiliate subcase, the system determines, using business rules, if the case is eligible for Auto-Approval. Auto-approved cases can be immediately completed and their reports submitted without any affiliate user intervention.



The following are the steps of an example Pega PV Outbound Workflow:

1. Pega PV Outbound retrieves a completed case from a safety database and creates a new Global Case in Pega PV Outbound.

2. From the incoming data, Pega PV Outbound finds that the case originated in the US, so it uses US as the source country for determining local and foreign reporting criteria.

3. Pega PV Outbound compares the products in the case to its global product registration information, and finds that the products in the case are marketed in the US, Spain, and Canada.

4. Pega PV Outbound then evaluates the case data against each possible destination’s reporting criteria to determine if the case parameters make it reportable for each of these destinations.

In this evaluation, Pega PV Outbound:

− Finds that the case requires expedited reporting in the US to the FDA as an E2B XML file to be submitted 7 days from the global case clock date.

− Determines that an affiliate will handle reporting for this product.

− Determines that based on case parameters, this case can also be auto approved, and does not need to be further evaluated by the US affiliate.

− Creates a local subcase for the US submission, generates the E2B XML file which it attaches to the US subcase, then places the E2B file into the appropriate US submissions management queue.

The system sets a Service Level Agreement (SLA) for this case of 7 days from the case clock date, but the case is auto-approved, automatically meeting the SLA. This subcase is resolved automatically and is now closed.

− Waits for responses (for example, ACK/MDN) from the submissions management system for this subcase.

5. Pega PV Outbound:

− Evaluates the global case data against the criteria for Spain and determines that it is also reportable to the Spanish Health Authority, which requires a CIOMS PDF for



− Creates a second local subcase for Spain, generates the CIOMS PDF from the case data, and attaches the completed form to the Spain subcase.

− Determines that this subcase is not eligible for auto approval (that is, requires local evaluation and/or local narrative) so it creates a review task and assigns it to the affiliate for Spain (an affiliate user may cover one or more destinations).

− The Spanish affiliate user receives an email notification of the new task from Pega PV Outbound and clicks on a link in the email to log into the Pega PV Outbound portal to review the case. They can also update designated fields (that is, local narrative) and the system automatically updates their local copy of the CIOMS form prior to approval.

− The due date for completion of this task is determined by a clock date and destination-based SLA, and if the Spanish affiliate user does not complete the task as the due date approaches, they will receive additional notifications from the system. When complete, the Spanish local subcase is closed, and the CIOMS submission is automatically placed in the appropriate submissions queue.

− Pega PV Outbound finds that the global case is also reportable in Canada. However, the company has an agreement with another manufacturer for safety reporting for their products in Canada. Pega PV Outbound is aware of this agreement and processes the local subcase for Canada accordingly. Pega PV Outbound creates a local subcase for Canada, then automatically emails a copy of the case in E2B XML to the designated Canadian business partner and closes the Canada local subcase.

When all subcases are completed, and all acknowledgements are received from submissions management, the Global Case is automatically closed as completed. When the global case completes, Pega PV Outbound then updates the source safety system with the completed status.

The entire history of the outbound case is retained in Pega PV Outbound. Any global case can be traced through its lifecycle and all local variants of submissions and reports are available for review at a later time.

Typical integrations Listening for and retrieving incoming cases.

Pega PV Outbound uses the Pega Platform Connectors to enable integration with a variety of systems to retrieve and receive incoming cases:

− Web Service – an incoming SOAP message can trigger new cases automatically in Pega PV Outbound. By default, Pega PV Outbound accepts E2B XML using this method, but you can configure Pega PV to accept other formats as well.

− File Listener - Pega PV Outbound includes a file listener connector that creates new cases whenever you place a file in a designated location. By default, Pega PV Outbound accepts E2B XML using this method, but you can configure Pega PV to accept other formats as well.

− Database Listener – Pega PV Outbound can use Pega Platform Integration capabilities for connecting to relational databases. You can employ triggers, polling, or other database mechanisms to allow Pega PV Outbound to initiate a case based on status changes or other events.



− Pega PV Inbound – You can use Pega PV Outbound to receive cases created in Pega PV Inbound.

See Chapter 4 in the Pega Pharmacovigilance 7.31 Implementation Guide for information on configuring how Pega PV Outbound retrieves and receives cases.

Returning status updates for submitted cases.

Pega PV Outbound can use a similar set of services to communicate case status back to the safety system from which the case originated.

− Web Service – upon successful submission and acknowledgement of receipt, Pega PV Outbound can send a SOAP message back to a safety system, referencing that system’s case ID to indicate submission status.

− File Listener- Pega PV Outbound may also place an XML file in a specified location for consumption by a safety system to indicate updates or status changes to a case.

− Database - Pega PV Outbound can write status and audit information directly back to the relational database tables to indicate a status update or submission.

See Chapter 4 in the Pega Pharmacovigilance 7.31 Implementation Guide for information on configuring status updates for submitted cases.

Placing outgoing submissions in submissions queue.

Pega PV Outbound automatically delivers approved submissions to a submissions management system for pickup and delivery. You can extend it to deliver submissions to any other system using any available Pega services.

− File System – by default, Pega PV Outbound includes a basic method of placing outgoing submissions content into a specified folder in a file system for pickup by a submissions management system.

− Extending to Other Repository Types – You can deliver outgoing submissions to additional types of repositories such as a document management system, or you can send to other systems directly using any of the available Pega Platform services.

− See Chapter 4 in the Pega Pharmacovigilance 7.31 Implementation Guide for information on configuring delivery of submissions and reports.

Monitoring for submission acknowledgement files:

You can configure Pega PV Outbound to monitor for response files from external submissions management systems. This can be used to track information returned from a destination (such as a regulatory gateway) that indicates whether a submission was received and if it was able to be successfully parsed.

− You can configure Pega PV Outbound to monitor submissions management folders for text or XML response files (such as MDN or ACK). It uses the standard Pega Platform file listener service and can be configured to retrieve response files.

See Chapter 4 in the Pega Pharmacovigilance 7.31 Implementation Guide for information on configuring status updates for submitted cases.



Automated emails to business partners:

Pega PV Outbound can automatically deliver submissions to business partners using email. Partners receive emails containing a PDF or XML submission attachment for any cases that involve products that they are linked to in the product table and that meet reportability requirements for the specified destination. For example, if the product Aspirin is listed in the product table as a US product, and is linked to partner, any safety reports for Aspirin that evaluate as reportable per the US rules are automatically delivered in the US submission format. You can find the email address Pega PV uses, to generate the email to the recipient partner, in the product table.

Other Integrations:

− Storing Reports and Submissions in a Repository with CMIS - you can optionally use the Pega Platform connector for content management systems (CMIS Connector) to optionally store submissions in a separate repository such as EMC Documentum, IBM FileNet, or Microsoft SharePoint.

− Using Externally Generated Submissions/Reports – instead of using the Pega Platform PDF eForm and (XML) file services to generate PDF and XML files, you can alternately configure the system to retrieve pre-generated submissions and reports from an external repository using Pega Platform file services.

− Product Registration/Mapping Data – Pega PV Outbound includes a basic built-in product management component that enables the mapping of products to regions and partners. You can classify the products by Name, ID, Destination, Market Status, Agency, and Partner. You can manage product mappings to locales and partners either internally or externally to Pega PV Outbound. The following are the three general approaches to bring product data into Pega PV Outbound:

- You can enter the product information directly into Pega PV Outbound (See Administrative functions, described in the next page, for information on how to manage product/locale/partner mappings).

- You can maintain product data in an external system (such as a global product registration system) and can integrate Pega PV Outbound with that system to extract product registration data on a per-transaction basis.

- You can maintain product data in an external system (such as a global product registration system) and can then batch-upload to Pega Platform on a periodic basis.

Standard report submissions XML reports Pega PV Outbound can generate XML files for submissions or for sending to business partners. By default, Pega PV Outbound generates E2B (M/R3) XML files. You can modify this base E2B template and extend it as needed, and modify specific regional variants linked to individual locales.

PDF forms and reports Pega PV Outbound can generate PDF forms and reports. It includes a standard FDA 3500A (MedWatch) PDF template and a CIOMS PDF. You can add other PDF forms and variations of



these basic forms using the Pega PDF eForm Accelerator. The PDF eForm Accelerator is part of the Pega Life Sciences Foundation and is included with Pega PV. It provides a tool for mapping data elements in Pega Platform and Pega PV Outbound to PDF eForm templates. See the Pega Life Sciences Foundation documentation for more information on adding and editing PDF eForm templates.

The following shows a PDF MedWatch Form.

Administrative functions Pega PV Outbound includes a default administrator role (Outboundsafetyadmin) that can view all the cases in the system, as well as create new destinations and products. You can add users and work queues for destinations from the Safety Admin portal.



Use the navigation pane to access other system functionality.

Managing destinations A destination is any regulator, partner, or other organization that may receive a submission or report from Pega PV Outbound. Each destination contains a user, a work queue, and a set of reporting rules. The reporting rules set the parameters that select the Adverse Events to send to this destination. You can manage the destinations from the Manage Reporting Rules section accessible through the Admin link in left panel. Here you can view, update, or create destinations.

Name Description Dashboard This is the first screen presented to the Safety Admin at login. It shows the current overall system

activity and lets the Safety Admin access work queues and view recent work. My Work Select this option to view all cases. Click the ID to display a new screen with subcases and attachments. Calendar View and open cases based on task deadlines. Reports View and create standard and custom productivity and analysis reports for the system. You can manage

regulatory submissions using Manage Reporting Rules but not from Reports. Admin Reporting rules — View, update, and create reporting rules and destination work queues for the system.

Product reportability — View, update and create products and partner mappings.



The Select Destination control lets you choose to view just the information for a particular destination.

1. You can elect a destination from the list and click Search to view that destination.

2. Click View All to view all destinations in the system.

3. Click View checked out to display any rules that are locked for editing in the system.

When displaying a list of destinations, the information is displayed in columns:

Destination – the name of the destination. It may be a country, regulator, or other entity.

Operator ID – the primary user associated with that destination. By default, the relationship between operators and work queues is 1:1, but any operator can be given access to any number of work queues. For example, the operator for Germany can be given additional access to the work queues for Austria and Switzerland. This is configured in the user’s profile or can be managed in the list under the Operator’s ID at the top left of the screen.

Work queue – the primary work queue associated with that destination. A work queue is a group queue to which local cases are routed for this destination. All users with access to this work basket see any cases that appear in the work basket and are notified per their individual profile settings.

Reporting Rules – the content of this column may vary by destination. Each destination may have from one to three reporting rules. There are three possible types of rules:

− Local Reportability – local reportability applies when the adverse event originates in this destination (typically a country or regulatory agency). Click on the LocalReportability rule label to open for review or modification.

− Foreign Reportability – foreign reportability applies when the adverse event does not originate in this destination, but the product (by name or ID) is relevant or available in



this destination. Click on the ForeignReportability rule label to open for review or modification.

− Auto Approve – the Auto Approve rule allows the system to bypass a user review step for any cases meeting its criteria. The case is still created for this destination but is automatically resolved and sent to the next step (that is, the submissions system). Auto Approvals still result in an audit trail recording. Click on the AutoApproval rule label to open for review or modification.

Create Rules – if any of the above reporting rules do not exist for this destination, you can create them by clicking here.

Managing product mappings In addition to reportability rules that determine the criteria for reporting to each destination, the Safety Administrator or delegated user can map different products to different destinations using the Manage Product Information tab.

From the Manage Product Information tab, click Search Products to display product mappings in the system. The list displays ten products per screen. If more than 10 products are returned, you can page through them using the navigation tools at the upper right of the Product List. You can also enter filter or search criteria in one or more of the fields at the top of the screen to reduce the number of products returned by the search.

Destination Name –– select or enter a destination to return only those products listed as available or relevant to that destination.

Product Name –– filter the list to a specific product name. By default this is a plain-text field, but can be configured as a lookup from valid product names.

Partner Name –– filter the list to those managed by a specific partner. By default, qualifying AE reports for this product and region combination are automatically emailed to this email address in the region-specific format. Other methods of delivery may be configured if required. A subcase is still created for partner cases, but is automatically emailed and resolved.



Agency Name –– can be used to filter by specific agencies. This does not necessarily need to be a top-level government agency. For example, products can be listed as FDA-CDER or FDA-CBER to differentiate product types.

Market Status –– used to filter products by market status, for example, premarket, marketed-prescription, and marketed-OTC.

The products returned by a search are displayed in a list. The columns display the following information:

− Product ID –– unique or destination ID of the product

− Product Name –– global or destination name of the product

− Destination Name –– name of the associated destination

− Market Status –– current market status in the destination

− Partner Email – if not blank, the email address of the partner who will receive this case through email if it evaluates to reportable for this destination

− Agency Name – name of agency or other recipient for this destination

− Deprecate – check here to retain the product information in the system, but not process cases for this item

By default, product fields in the list are read-only. Double-click on a field in a row to edit the values for that row.

You can add new product rows by clicking the Add product button.

External product data You can manage product information exclusively in Pega PV outbound. However, for organizations with large product catalogs or existing global product registration data, it may be advisable to populate or integrate the information in this list with an external system. Options include direct integration to product registration data, where the data is accessed by Pega PV



Outbound in real time, or if performance is negatively impacted, providing a batch upload of product master data into this system. You may alter the information displayed to reflect external product data models, with corresponding Pega PV properties being populated by that data to enable assessment by the Pega PV business rules.

Adjusting the SLA clock date Adjusting the clock date resets one or more SLAs for a case. You can adjust the clock date manually to reflect new case information in the case. You can also configure clock date adjustments to occur automatically based on other events if required. Use the Modify SLA command to perform clock date adjustments. There are two types of Modify SLA that you can perform:

Modify Parent Case SLA – by default, only the Safety Administrator can modify the SLA for the entire (top-level) case, which results in all subcases being re-evaluated and each of their SLAs reset.

Modify Subcase SLA - an Affiliate can modify SLAs for their subcases only. This does not impact the parent case, only the subcases in their work queues. The Safety Administrator can also modify individual subcase SLAs.

Modifying an SLA is an auditable event that results in an audit trail entry.

Modifying a parent case SLA 1. Open the case in the Safety Admin portal. Under Actions, select Modify SLA.

Updating an SLA requires a new start date and a reason for the change. The reason is recorded along with the user ID to the audit trail for this case.

2. Select Update SubCases to confirm that all subcases under this parent case will have their SLAs updated as well.



3. Click Submit to update the SLA.

This updates the SLA for the parent case and all subcases. Modifying an SLA is an auditable event that results in an audit trail entry.

Distributing submissions to external parties In addition to managing the distribution and review of submissions and reports for affiliate users, Pega PV Outbound supports automatic distribution of submissions and reports to external users using email. This feature enables the management of affiliate and external or partner distributions from within the same case. This capability is driven by partner mappings in the Product Information tab.



When the system evaluates reportability for a case, if it qualifies a case as reportable to a destination that includes a partner email, it creates a subcase, but instead of routing it to an affiliate for that region, it generates the appropriate report or submission along with an email message (created using a configurable template) and automatically sends the email to the partner email address associated with that product.

Since any product for any region can have its own partner contact, this can support any scenario from a single partner managing a single product for a single country, all the way to complex multi-region/multi-product agreements. Full auditability is always provided, as each case retains the partner distribution record, so even if partner mappings change over time with new agreements, each case still retains its historical distribution information.

The default template for outbound email can be found in the Developer Portal:

PegaLS-FW-AECPFW-Work > Process > Correspondence > AECPReport

The default template can be configured or replaced, and can be specialized to automatically deliver different email content to different partners as required.


The Pega Pharmacovigilance Exchange (PVX) module enables life sciences organizations to manage Pharmacovigilance Agreements (PVAs), which define the responsibilities for partners around various activities for cross-licensed products. The PVX module helps enforce Standard Operating Procedures (SOPs) and policies, and manages the execution of those commitments contained within PVAs on a global basis. The PVX module helps ensure regulatory compliance and monitoring functionality and prevents duplication of pharmacovigilance activities by various partners.

PVX module provides following capabilities:

Draft/create agreements — create new agreements involving different contractual parties, business agreement types in various markets as per life science organization’s Standard Operating Procedures (SOPs) and policies.

Define various responsibilities — PVA Leads can define responsibilities for parties around various activities for cross-licensed products.

E-sign agreements — PVA Leads must e-sign an agreement before it becomes active. Life Science industry foundation is leveraged to authenticate PVA Lead by capturing user id and password. Entry is created in audit table upon successful login to capture who performed the action with timestamp.

Create new revisions — PVA Leads can create new revised agreement once the ongoing version is about to expire or no longer valid. A new agreement is created and attached to the original agreement with new version number to easily track all the revised agreements.

Integration Capabilities — connect to your data sources to fetch contact info, product details, territories and other important agreement data that already exists in other systems.

Perform periodic reviews — the system can automatically trigger periodic reviews or PVA Leads can manually perform periodic reviews on active agreements to verify if the agreement content needs to be revised.

Create & monitor tasks for various responsibilities — PVA Leads can create tasks for different responsibilities and assign to appropriate contact leads. This allows companies to properly monitor and track responsibilities and identify any actions have been taken in timely manner.

Typical PVA workflow A typical PVA case starts by creating or defining a new PVA agreement involving different contractual parties.

Creating an agreement While logged into the case manager portal as a PVALead, click + Create > Agreement to create a new PVA. The PVA case management flow starts and the Capture Agreement details screen appears.

Pega Pharmacovigilance Exchange (PVX)



The General Information section allows you to capture the detailed specification regarding the PVA such as Lead PVA Party, Licensing Agreement type, PVA Lead responsible for the PVA and other general information related to the PVA.

The PVA Lead user can select multiple values for Contractual Parties, Business Agreement Types and Territories by clicking appropriate Add buttons.



The Product Information section allows the PVA Lead to capture the products that are involved in the PVA. The PVA Lead has the option to add multiple products by clicking the Add item link.

The PVA Level Information section allows the PVA Lead to capture the length (PVA Level) of the agreement, define the PVA Level approver and the text area to capture justification whenever the PVA Level is changed.

Defining timeline for different stages The Timeline screen allows the PVA Lead to capture the timeline for different stages to ensure that each stage is moving along in a timely manner. The PVA Lead can plan current and future stages timeline by entering the planned dates. The PVX application captures actual dates when the agreement enters and exits the particular stage.

The PVA Lead can also enter comments to capture justification for timeline for each stage.



Defining responsibilities The Responsibilities screen allows the PVA Lead to define responsibilities for each category. The PVA Lead has the option to add multiple entries for each responsibility. This functionality benefits the PVA Leads in systematically capturing the responsibilities in an accurate manner.



Performing periodic reviews A PVA automatically moves to periodic Review assignment when the PVA Level SLA is triggered. An SLA is configured to start periodic review two months before the PVA Level deadline. You can change this in the implementation layer. The PVA Lead also has the option to manually start the periodic review before the SLA is triggered by clicking on Other Actions >Periodic Review. While performing periodic reviews, the PVA Lead can create a new revision of the agreement by selecting the check box. Then when clicking Submit, a new PVA version is created.



Creating an agreement revision Once the PVA becomes Active PVA Lead can create a new revision by choosing the Agreement Revision option from the Other Actions drop-down menu.



A new revision has been created, but the old version is still Active. Once the new revision becomes Active, the old version status is updated to Superseded.

Searching PVA. The Search PVA screen allows you to search for agreements using Generic Name, Contractual Parties, and Territory.

Monitoring tasks The PVX module allows you to create monitoring tasks for each defined responsibility in a PVA. This functionality allows companies to properly monitor and track responsibilities and identify any actions have been taken in timely manner.



Once a PVA becomes Active, the PVA Lead can select Actions >Create Task.

Administrative functions The Pega-provided PVX Admin functionality allows business admins to maintain Lists of Values (LOV), LOV Category, and Contractual Party values. These values are leveraged in drop-down lists, radio buttons, and autocomplete controls in UI screens. The Admin functionality allows Business Admins to add, edit and activate or deactivate the values. You can extend this functionality to match your business requirements.




Data classes define the data structures for supporting information that the application uses to process work. PegaLS-FW-AECPFW-Data- contains reusable data classes. Please refer to PDN page for more information: https://pdn.pega.com/data-storage-pega-pharmacovigilance

Sample data For sourcing sample data for some of the Pega PV data entities like Sender, Subject, and Reporters there are database tables set up in PegaData schema. Please refer to sample data PDN page for more information: https://pdn.pega.com/sample-data-pega-pharmacovigilance

Data model

https://pdn.pega.com/data-storage-pega-pharmacovigilance

https://pdn.pega.com/sample-data-pega-pharmacovigilance


The following table describes the roles, user type, access group, and default portal shipped with the Pega PV application. You can extend all these roles further.

Pega PV inbound

User User type Access group Application Portal InboundAdmin Developer PegaPVInbound:Administ

rators Inbound (PegaPVInbound:07.31)

Designer Studio(Default)

CaseManager(Alternate) PIIntakeUser User PegaPVInbound:PIIntake

User Inbound(PegaPVInbound:07.31)

CaseManager

MRSpecialist User(Approver) PegaPVInbound:MRSpecialist

Inbound(PegaPVInbound:07.31)

CaseManager

QCReviewer User(Approver) PegaPVInbound:QCReviewer

Inbound(PegaPVInbound:07.31)

CaseManager

Pega PV outbound

User User type Access group Application Portal OutboundAdmin Developer PegaPVOutbound:Admini

strators Outbound(PegaPVOutbound:07.31)

Designer Studio(Default)

CaseManager(Alternate) OutboundSafetyAdmin

User PegaPVOutbound:SafetyAdmin

Outbound(PegaPVOutbound:07.31)

CaseManager

Pega PV inbound and outbound integrated

User User type Access group Application Portal PegaPVAdmin Developer PegaPV:Administrators Integrated(PegaPV:07.31) Designer Studio(Default)

CaseManager(Alternate) PegaPVUser User PegaPV:Users Integrated(PegaPV:07.31) CaseManager

Pega PV exchange

User User type Access group Application Portal PVXAdmin Developer PegaPV:Administrators Integrated(PegaPV:07.31) Designer Studio(Default)

CaseManager(Alternate) PegaPVUser User PegaPV:Users Integrated(PegaPV:07.31) CaseManager

Roles, access groups and portals



Visit the Pega Discovery Network (PDN) For release notes, and product guides go to:

Visit the Mesh page To engage in community discussions and share knowledge go to:


The chapter provides a step-by-step overview of the default Pega PV Inbound data capture process. Since Pega PV is built on the Pega Platform, everything in this chapter is configurable for your implementation. You can adjust user interface elements, add or remove data elements, modify business rules, and even re-order the main workflow to suit the needs of your implementation. In this chapter, the basic Pega-provided configuration is used.

1. Log in to the Pega PV application.

Username: pegapvuser

Password: rules.

The default case manager portal appears. You can configure and rearrange the portal layout using the gear icon on the rightmost side.

2. Select Product Issue Intake from the New menu in left panel.

The Product type selection screen appears. Here you have an option select the product type you wish to crate the case for. You also have an option to manually upload the MedWATCH pdf file. System will parse the data from the PDF and populate the corresponding data elements in the UI in the next screen.

Appendix A: Pega PV – Capturing case data with screenshots



3. This screen only appears if you selected an option to upload the MedWATCH form file in previous screen.

4. An emulated MedWATCH UI is displayed for you to quickly compare and manually update the data system was not able to parse and populate. The uploaded file is also attached as case attachments for easy access.



5. The mapping screen is displayed for you to quickly compare the MedWATCH data with mapped E2B Data. PV application is configured to map most of the elements but you can



extend this further by leveraging NLP systems in your application or you can manually do the mapping for the remaining elements.

6. The edit all screen is designed and arranged in stacked structure layouts to easily capture and review the required and optional fields as per E2B R3 data model.



3. Complete the Case Type field by specifying whether this case is New or a Follow Up.

If you select Follow Up, different set of follow up options appears, select the type of follow up and click on Search for Case button, a dialog box appears where you can select the original case. The Subject, Reporter, and Product data is automatically copied from the original case to the follow-up case.

Note: You cannot create a follow-up case without selecting an original Case to follow-up.



4. Complete the Date of Receipt (read-only date and timestamp of the current date and time), Date of Intake (date the case was actually submitted or received), Mode of Receipt, Country of Occurrence, and External Case ID. Click Next to continue.

5. The next section lets you enter the Reporter information. The Reporter screen enables you to either look up a reporter from an existing linked data source or to enter data for a new reporter. You can enter multiple reporters for a single case, but you must select ONLY one Primary Reporter.

To search for an existing reporter, click the Search existing reporters link to open the search screen. Begin typing in the fields at the top of the screen to narrow your search.

6. Next section allows you to search and select a Subject in a similar way as Reporter. You can add subject information in one of three ways. You can look up a subject from an external data source (similar to reporter lookup – must be configured in implementation), enter it manually, or select Reporter as Subject.



Since reporter does not generally include some required subject data, you must add some additional data before you add a reporter as a subject. Upon clicking the Reporter is the subject checkbox, a new drop-down option appears. Confirm the existing reporter information, and add any additional required information (required fields have an asterisk next to them).

In this same screen you also have the option to include Subject medical history and drug history entries. Click Add parent information checkbox to add the subject’s parent information. Here you also have the option to include parent medical history and drug history.

7. Product information section is designed to capture drugs as well as device information. You have an option to add multiple drugs. You can search and select drugs by clicking Add drug link. A new modal popup window is displayed where you can search products from your organization internal product repository, or from WHO drug dictionary tables. You can also add a new product type if you are not able to locate the product type involved with the event.



8. Click Next button once you have searched and selected the product. On the next screen, you can fill in all the necessary information you have been provided from the reporter. The data fields are structured and displayed as per the E2B data model.



9. Click Finish once you have entered all the Product details. Product details will be copied to the Product page. Repeat step 11-14 for multiple drugs involved.

10. Once you have identified the product, you can also capture complaint data by clicking on the log a complaint link.

11. The screen is configured to capture some basic complaint details which can be further extended. If you select Replacement or Refund option then you must specify the receipient information by selecting the Reporter or Subject option.



12. If the Event also involved medical devices then scroll down to Associated devices section.

Fill in all the necessary information in all the tabs and identify the product involved as AE suspect and/or Complaint

13. Expand Adverse reactions section to capture multiple adverse reactions. Click Add reaction link search & select the appropriate MedDRA codes for the adverse reaction. Here you can search using different search options or select the code directly by selecting Select from hierarchy option.



14. Click Next once you have found the appropriate code.

Note: You can just click Next if you couldn’t find the matching MedDRA code. You can describe the details by providing the adverse event Verbatim/description in the next screen.

15. Capture lab results details by expanding the Lab results section. You can attach any lab x-rays or other lab related reports in Lab reports section.



16. The Adverse Event questionnaire is similar to the Product Complaint questionnaire, but is used to gather detailed information about Adverse Events for all the products involved. (You can easily define, modify, and manage questionnaires using the PegaSurvey Management utility. You can add or modify questions and question logic using the PegaSurvey configuration pages. See the PegaSurvey documentation on the PDN for more information on configuring questionnaires.)



17. Click Submit once you have entered all the necessary case details.

The next screen provides two sections:

One is the Product Relatedness Matrix. You can identify relatedness of products to the adverse events for different parties. You may add multiple rows per product for any number of parties based on assessments of relatedness.

The second one is system-generated assessment of the AE case based on information gathered throughout the data capture process. You can configure the logic used to set these parameters, and by default, you can adjust the outcomes. However, you can also configure the system to make these parameters read-only if needed.



We have configured Part 11 audit feature on this screen, which will require you to re-authenticate yourself if you do feel like overriding the system suggested adverse event assessment. In that case you will have to click Review and Confirm Audited Modifications button and in the popup window you will have to re-enter your user name and password. You can either provide the generic reason or provide separate reason for each changes.



17. The next screen displays the narrative from case data you captured so far which can be used to quickly review the information in narrative format or can be shared with other affiliates by downloading the system generated PDF from Case attachments. You also have an option to edit the system-generated narrative by clicking on the Edit narrative link. Clicking Submit generates a new PDF.

Note: The Case is automatically routed to the Medical Review Specialist when certain conditions are met such as (fatality, hospitalization, serious or unlabeled AE). The specialist can review the case, make necessary changes, or request more information from Intake user. You can configure this review step just as you can configure all the steps in the process. You can remove the conditions or add additional conditions as needed. The system can be configured to route the case to multiple reviewers, or bypass the review process completely and send the case as-is for reporting and distribution. To view the Specialist review step, you will need to log out of the system and log back in as a Medical Review Specialist Operator that is, mrspecialist).

18. Log in to the portal as MRSpecialist (password: rules). Click the My Work link in the left navigation pane.



The review task appears as a subcase – or child object to the main case. From within the subcase, you can always review the entire parent case, including all data and attachments.

19. Double-click the Review Adverse Event link.

The subcase task displays the next screen.



The MRS sees the current case assessment, and can review any additional case data. The MRS has the option to make any necessary modifications before approving, MRS can also reject the case and send it back to the Intake user.

Note: If MRS makes any changes the system automatically detects audit changes and routes the case to Quality Review Specialist for quality review. You can configure this review step just as you can configure all the steps in the process, you can remove the conditions or add additional conditions. The system can be configured to route the case to multiple reviewers, or bypass the quality review process completely and send the case as-is for reporting and distribution. To view the quality review step, you will need to log out of the system and log back in as a Quality Review Specialist Operator (that is, QCReviewer).

After all the reviews are complete the case is then returned to the originating Intake User.

20. Log back in as an original Intake user (that is, PegaPVUser) to complete the case review.

21. When all reviews are complete (in the default configuration there is only one), click Submit to continue.

This completes the Pega PV Inbound process and initiates any additional actions (configuration is required to define additional actions).

You can configure additional actions that typically include either:

Sending the case data directly to a safety system such as Oracle Argus.

Sending the case to Pega PV Outbound for report generation, distribution, review, and submission to regulatory authorities.



If your implementation is configured for both Pega PV Inbound and Pega PV Outbound, you can continue to advance the case and review any reports or submissions that have been routed to you by the system.

For example, in the image above, the Pega PV Inbound system has been configured to directly continue the process from Inbound to Outbound, and on completing the review step, you see both local as well foreign reports generated by Pega PV Outbound.

Date post:	26-Oct-2021
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Pega Pharmacovigilance - Product Overview

Documents