20Investigating Adverse Events and Complaints
Investigating Adverse Events and Complaints
This chapter covers the following topics:
About Investigating Adverse Events and Complaints
This chapter describes review and investigation of a product complaint or adverse event using the Siebel Adverse Events and Complaints Management (Siebel AECM) module. This typically involves entering more information about the product issue, determining if the issue should be reported, and creating an activity plan for researching and addressing the issue.
Scenario for Complaint Investigation
This scenario is an example process performed by the Siebel administrator and the quality manager. Your company might follow a different process according to its business requirements.
This process is designed to illustrate the functionality of the Siebel AECM.
The Siebel Administrator
The administrator sets up the assessment and activity templates that the quality manager uses in the course of investigating product issues.
Before creating templates, the administrator consults with the quality manager who thoroughly understands the company’s business processes. The quality manager suggests the text for the templates that administrator sets up and reviews the templates before roll out.
The Quality Manager
The quality manager reviews the complaints assigned to her. Her job is to determine if an investigation of the complaint is required and if the complaint needs to be reported to a regulatory agency.
The quality manager notices that a new product issue has been added to her queue. This complaint was initially reported as a service request and was escalated by a call center agent. It concerns a failure in a blood analyzer.
Upon taking ownership, the quality manager reviews the service request associated with the product issue, including the work done by the service engineer.
Next, the quality manager contacts the customer and obtains more details about the issue. She discovers that there are two product issues associated with this incident: the cartridge might have been faulty as reported in the service request, but also the third-party reagents used might have exacerbated the problem. The quality manager creates a second product issue to investigate the reagents.
To help guide the investigation and keep it on schedule, the quality manager applies an activity template that generates an activity plan — a list of activities that need to be carried out, some by her and some by other employees.
Her next step is to determine if the product issues are reportable. She answers the series of questions in the Assessments view and looks at the score. Scores of 75% and higher indicate that the product issues should be reported.
After completing the review, the quality manager changes the status of the product issue records to Review Complete. This locks down some data in the complaint file and makes other data read-only.
Process of Adverse Events and Complaints Investigation
This example process represents the tasks that are carried out in the Scenario for Complaint Investigation.
Administrator Procedures
Creating Product Issue Assessment Templates
The purpose of the assessment is to quantify an evaluation of the product issue. The assessment template is made up of a series of questions about the product issue with an associated list of possible answers. Each question and each answer is assigned a weighting from which a single score is calculated.
This value can be used to indicate the risk associated with the issue or whether the issue should be reported to the regulatory agency.
This task is a step in Process of Adverse Events and Complaints Investigation.
To create an assessment template
Refer to Siebel Applications Administration Guide for information about how to create assessment templates. Make sure to set the template type to Product Issue.
Creating Product Issue Activity Templates
Product issue activity templates are used to create a standard set of activities that the quality manager and other employees do to investigate product issues.
This task is a step in Process of Adverse Events and Complaints Investigation.
To create a product issue activity template
Navigate to the Administration - Data screen, then the Activity Templates view.
In the Activity Templates list, create a new record and complete the necessary fields.
Set the Type field to Product Issue.
Leave these fields blank: Sales Stage, Sales Method, Protocol Title; they do not apply to product issue activities.
Associate individual activities with the template, as described in Siebel Applications Administration Guide.
Note: Lead times for product issue activities are defined as the amount of time between the start date for an activity plan and the date that the selected activity should start.
Reviewing and Editing the Product Issues
Early in the investigation, the quality manager reviews, updates, and adds information to the product issue record. This record becomes the adverse event or complaint file for the investigation.
There are many fields in the product issue record. Some are filled in by the call center agent, some automatically, and others by the quality manager. Of particular importance are those fields that are used to populate the regulatory reports. For more information, see Regulatory Reporting
This task is a step in Process of Adverse Events and Complaints Investigation.
To review and edit a product issue
Navigate to the Product Issues screen, then the Product Issue List view.
In the Product Issues list, select a record.
In the Product Issues applet, modify the fields in the record as required.
Some fields are described in the following table. Note that the letter and number combination in the last column indicates how this field maps to the 3500A form.
Field Comments Mapping to 3500A Form Account
The name of the account associated with the product issue.
E1
Address
Account address - street address.
E1
Alert Age
The number of days since the product issue was identified as reportable.
If an initial report has been filed, the alert age is the number of days that the product issue was marked reportable before the report was filed.
Alert Date
The date when a representative of a company becomes aware that the event needs to be reported.
For example, when:
A call center agent captures the adverse event or complaint.
An assessment indicates that the event is reportable.
Area
The general categorization area for the product issue.
This field is constrained by Type.
City
Account address - city.
E1
Contacts
(Contact Last Name in list)
The last name of the customer contact associated with the product issue.
These contacts can also be entered using the Contacts view of the Product Issues screen, then the Contacts view.
E1
CSN
Customer service number. A unique number to identify the account.
E1
Evaluation
This field appears in the list applet. It also appears in the form in the Investigation view.
First Name
The first name of the investigator carrying out a particular clinical trial at a site.
First Name
(Contact First Name in list)
The first name of the customer contact associated with the product issue.
E1
Investigator
The last name of the investigator carrying out a particular clinical trial at a site.
If the product issue is associated with a clinical trial, this field is auto-populated with the last name of the investigator at the protocol site, specified in the Protocol number field.
Mfg Report #
This field appears in the list applet. It also appears in the form in the Importer view.
Occupation
Occupation of the contact.
This is copied from the value of the Type field in the Contacts screen.
E3
Open Age
The number of days since the product issue was opened, or, if the product issue is closed, this is the number of days that the product issue was open.
Phone #
Contact’s work phone number.
E1
PI #
Unique number to identify the product issue. It is auto-generated when the product issue is created.
Postal Code
Account address - postal code.
E1
Protocol #
Protocol number identifies the clinical trial at a site. If regulatory report is an IND safety report, enter the protocol number.
G6
Provider
Indicates if the contact is a health professional.
E2
Received (Received Date in list)
The date when a company representative became aware of the event.
Reported FDA
Indicates if initial reporter sent a report to the FDA.
E4
SR #
The service request from which the product issue was created.
State
Account address - state.
E1
Status
The current status of the product issue.
The status of the product issue can be changed by the owner of the product issue, using the Review Complete, Close, and Reopen buttons.
Changes to this field are tracked in the Approvals view.
Sub Area
This further refines the area categorization. (The Area field constrains this drop-down list.)
Sub Status
The Status field constrains this drop-down list.
In the Event Detail applet, modify the fields as required.
Some fields are described in the following table. Note that the letter and number combination in the last column indicates how this field maps to the 3500A form.
Field Comments Mapping to 3500A Form Event Type
Describes the type of event.
B1
Event Date
The approximate date of the adverse event.
B3
Description
(Event Description in the list)
Detailed description of the event
B5
# Occurrences
Number of times the event occurred before it was reported
External Products
List of other medical products (for example, drugs, medical devices) used by patient at the time of the event and dates of use
C10 or D11
Tests/Data
All appropriate relevant test and laboratory findings and dates
B6
Life Threatening
Life Threatening
B2
Disability
Disability
B2
Hospitalization
Hospitalization
B2
Congenital Anomaly
Congenital Anomaly
B2
Relevant History
Relevant history, including preexisting medical conditions
B7
Death
Death
B2
Required Intervention
Required Intervention
B2
Date of Death
Date of Death
B2
Other
Describe the reported outcome if it was not covered in the previous selections
B2
In the Products applet, create new records and complete the necessary fields as required.
Some fields are described in the following table. Note that the letter and number combination in the last column indicates how this field maps to the 3500A form.
Field Comments Mapping to 3500A Form Product
The name of the product associated with the event
C1
Lot #
Lot number of the product
C6, D4
Asset #
Asset number for the product
D4
Serial #
Serial number for the asset
D4
Mfg Name
Full name of the manufacturer of the product
D3
Mfg Date
The date the product was manufactured
H4
Expiration Date
Expiration date of the lot or product
C7, D4
Labeled Single Use
Indicates if the device is labeled for single use
H5
Device Operator
Type of person operating or using the suspect medical product on the patient at the time of the event
D5
Device Available
Indicates if the device is available for evaluation by the manufacturer
D10
Return Date
Date that the device was shipped to the manufacturer
D10
Device Type
Generic or common name of the suspect medical device
D2
Reprocessed
Indicate if this is a single-use device that was reprocessed and reused on a patient
D8
Reprocessor
Name and address of the reprocessor of the reused single-use device
D9
NDC#
National drug code #
C9
Part #
Part number
D4
Implant Date
The implant date or best estimate for medical devices that are implanted in the patient
D6
Explant Date
The date or best estimate for medical devices removed from a patient
D7
Street Address
Manufacturer’s street address
D3
City
Manufacturer’s address: City
D3
Postal Code
Manufacturer’s address: Postal Code
D3
State
Manufacturer’s address: State
D3
Model #
Model number
D4
Catalog #
Catalog number
D4
Dose Per Unit
Dosage for each unit of drug
C2
Frequency
Frequency of drug administration
C2
Route Used
Route used to administer the drug
C2
Indication
The indication for which the product was prescribed or used in this particular patient
C4
Therapy From Date
The date drug administration was started (or best estimate)
C3
Therapy To Date
The date drug administration was stopped (or best estimate)
C3
Event Abated
Event abated after use stopped or dose reduced
C5
Reintroduce Reoccur
Event reappeared after reintroduction
C8
Review any service requests associated with the product issue as follows:
Drill down on the product issue record.
Click the Service Request tab.
Drill down on the SR #.
Creating Multiple Product Issues Related to One Service Request
Only one product issue can be created directly from a service request (using the Create Product Issue button on the Service Requests screen). However, in the Product Issues screen, the quality manager can create additional product issues related to the service request and the original product issue.
Here are some examples where multiple product issue records are needed:
A medical kit contains a drug and a device. The drug and the device might have caused the event. Separate adverse event and product complaint investigations have to be completed.
There are several products involved with the adverse event or complaint and the quality manager wants a unique product issue for each product.
This task is a step in Process of Adverse Events and Complaints Investigation.
To create a new product issue
Navigate to Product Issues screen, then the Product Issue List view.
In the Product Issues list, drill down on a product issue.
Click Create Related PI.
This starts a workflow (LS Medical Product Issue Create Related PI), which creates a new product issue record, copying fields from the current product issue.
For more information about the workflow, see About Configuring Create Related PI and Review Complete Buttons.
In the Event Detail applet, modify the fields as required.
In the Products applet, create a new record for each product that you want to associate with the issue and complete the necessary fields.
Creating Product Issue Activity Plans
A product issue activity plan is a list of activities associated with the product issue. The quality manager applies an activity template, suited to the type of product issue being investigated. The activity template sets up predefined activities that the quality manager and others follow to complete the product issue investigation.
This task is a step in Process of Adverse Events and Complaints Investigation.
To create activities for product issue investigation using a template
Navigate to Product Issues screen, then the Product Issue List view.
In the Product Issues list, drill down on a product issue.
Click the Activity Plans tab.
In the Activity Plans list, create a new record and complete the necessary fields.
Some fields are described in the following table.
Field Comments Planned Start
Make sure that this date is correct before you choose a template. The due dates for the template-generated activities are based on this start date and on the lead time set in the template.
Template
Only templates whose type is Product Issue can be selected in this field.
In the Activities applet, modify the existing activities or create new activity records as required.
Assessing If a Product Issue Is Reportable
Assessments allow end users to calculate a single numerical value based on their answers to questions about the product issue. An quality manager can then use the assessment score to decide how to proceed with the investigation.
These are some example assessment questions used to determine if a product needs to be reported:
Was there any patient injury? {No, Mild, Moderate, Severe}
Was there a labeling problem? {No, Yes}
Did the product function according to specification? {No, Yes}
This task is a step in Process of Adverse Events and Complaints Investigation.
To assess a product issue
Navigate to Product Issues screen, then the Product Issue List view.
In the Product Issues list, drill down on a product issue.
Click the Assessments tab.
In the Assessments list, create a new record and complete the necessary fields.
For example, in the Template Name field, select the assessment template that has been prepared for you. The application fills in other fields in the record when the record is saved.
In the Assessment Attributes applet, enter a value for each attribute.
The assessment score and percentage are calculated and shown in the Assessments list.
Completing Adverse Events and Complaints Reviews
The exact meaning of the adverse event or complaint review status depends upon your business process. For example, it could indicate that there is sufficient data to begin a second phase of the investigation (trend analysis and recreation of the problem in the lab).
As part of the review process, the quality manager changes the status the record to Review Complete. An important effect of changing the status of a product issue to Review Complete is that a number of key fields are locked down and others are made read-only.
This task is a step in Process of Adverse Events and Complaints Investigation.
To complete a review of a product issue
Navigate to Product Issues screen, then the Product Issue List view.
In the Product Issues list, drill down on a product issue.
Click Review Complete.
This starts a workflow (LS Medical Product Issue Review Complete) that:
Changes the status of the product issue to Review Complete
Authenticates the user
Locks down these fields:
Primary Contact first and last names
Contact work phone #
Reported By
Account Name
Account Address
Product
Device Type
Part #
Makes these fields read-only:
Account
Account Address
Date of Event
Summary
All patient information (on Patient view)
Description
For more information about the workflow, see About Configuring Create Related PI and Review Complete Buttons. For more information about field lockdown, see Closing Adverse Events and Complaints.
About Configuring Create Related PI and Review Complete Buttons
There are two buttons associated with adverse events and complaints investigation. You can configure the workflows and fields copied for these buttons.
You can modify workflows to suit your own business model using Siebel Business Process Designer. For more information, see Siebel Business Process Framework: Workflow Guide.
LS Medical Product Issue Create Related PI Workflow
This workflow is initiated from the Create Related PI button on the Product Issues screen.
The workflow appears in the following figure.
Workflow Description
This workflow performs the following actions:
Creates a new product issue.
Copies data from the original product issue to the new product issue.
Makes the new product issue the active record.
Changing Which Fields Are Copied to the New Product Issue
When the Create Related PI button is used to create a product issue, data from various fields are copied from the original product issue record to the new product issue record.
To change which fields are copied when a product issue is created
Use the Data Transfer Utilities to edit the LS Medical PI Create Related PI data map object.
For information about the Data Transfer Utilities, see Siebel Finance Guide.
LS Medical Product Issue Review Complete Workflow
This workflow is initiated from the Review Complete button on the Product Issues screen.
The workflow appears in the following figure.
Workflow Description
This workflow performs the following actions:
Checks if the user is the primary owner of the product issue. If not, the workflow ends.
Checks if the product issue has already been processed. If it has, the workflow ends.
Calls the LS Medical User Verification workflow.
If the user authentication is successful, copies the lockdown fields, makes some fields read-only, and changes the status to Review Complete.
LS Medical User Verification Workflow
This workflow authenticates the user’s name and password. This workflow is called from other workflows.
The workflow appears in the following figure.
Workflow Description
This workflow performs the following actions:
Calls the Authentication business service to verify the user name and password. The Authentication business service calls two methods to perform this action as follows:
ValidateSessionUser. This method validates that the logged-in user is the current session user.
Authenticate. This method checks that the supplied username and password are valid in the system.
If the authentication passes, returns to the original view and sets the result code to 100—passed.
If the user name and password are expired, shows an error dialog box and sets the result code to 200—expired.
If the authentication fails, increases the result code by 1 and on the third failure logs the user out of the application.
About the LS Medical Product Issue Service Business Service
The LS Medical Product Issue Service is based on the class CSSServiceLSProductIssue. It is a placeholder for the business services used by Siebel AECM.
Customizing the LS Medical Product Issue Service
The LS Medical Product Issue Service business service is written in C++ and cannot be modified. However, the methods in this business service are modular and can be used in workflows that you create.
The LS Medical Product Issue Service Business Service Methods
The LS Medical Product Issue Service has three methods. These are described in the following table.
Table LS Medical Product Issue Service Business Service Methods
| Method | Description | Used in Workflow |
|---|---|---|
GenerateReportNum |
Generates report numbers for MedWatch and MDV reports as follows.
|
LS Medical Product Issue RR Submit |
Logoff |
Logs out the user. |
LS Medical User Verification |
Query |
Queries with the input search spec and sort spec. |
LS Medical Create Related Product Issue |