RFPAttachment4FAERS-II_RequirementsSpreadsheet_Amendment0001.xls
XLS spreadsheet 657 KB Posted
- Attached to
- FDA's Adverse Event Reporting System (FAERS) II
- Solicitation number
- FDA-SOL-18-1192468
About this file
RFP Attachment 4: FAERS II Requirements_Amendment0001
View the file
Other files
Show all 19
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Instructions: Below are the definitions of the columns in the worksheets "Functional Requirements" and "Non-Functional Requirements". | |||
| Note: The requirement columns from "A to F" are protected with password. Offerer/Vendor must respond by filling out Columns G, H, I , J, K, L, and N | |||
| Column Location | Column Heading | Column Description | Notes |
| Column A | Req ID# | A number given to uniquely identify each requirement. | All parent requirements are bolded |
| Column B | Description | Describes the requirement. | All parent requirements are bolded |
| Column C | Category | Defines a functional category for every requirement based on functionality | Indicates the functional area for the requirement. |
| Column D | Sub-Category | Defines a functional sub-category for every requirement based on functionality | Indicates the functional area for the requirement. |
| Column E | Notes | Notes | Indicates the requirement Notes. |
| Column F | Must Have | Must Have requirements | Indicates system provides functionalities in line with "must have" requirment i.e. Mandatory requirement |
| Column G & H & I | FM or C or CM | Please respond to each requirement noting with a 'Y' for 'Yes' or 'N' for 'No'. Each requirement should have one 'Y' response and two 'N' responses | |
| Column G | FM | Fully Meet by Out-of-the-Box | Out-of-the-Box: Any functionality that comes shipped directly from the software vendor, works within the product immediately after installation, requires no effort to implement or maintain, and can be used by users right away. |
Enter "Y" for "Yes" and "N" for "No" in the cell.
| Column H | C | Configurable | Configurable is defined as any functionality that can be created using built-in workflow tools that are shipped directly from the vendor to tweak or fine-tune product parameters, such as: adding fields, changing field names, modifying drop-down lists, or adding buttons. To be considered configurable, functionality is forward-compatible with future vendor software release upgrades. It does not require access to the software code, and can be performed by Information Technology (IT) personnel or business users with limited training or the use of user guides and manuals. The time-frame for configurable items is from a couple of minutes to a less than 8 hours. Enter "Y" for "Yes" and "N" for "No" in the cell. |
| Column I | CM | Cannot Meet | Cannot meet is defined as requirements that do not fully meet OOTB or are not configurable and requires customization. Customization as any functionality that is not shipped directly in the tool and requires code/logic changes or modifications to the product software code, performed by Information Technology (IT) personnel. The functionality delivered by customization should be forward compatible and should be part and parcle of the core corporate product. The time-frame for customizable item is greater than 8 hours and must be fully implemented prior to user acceptance. |
Enter "Y" for "Yes" and "N" for "No" in the cell.
Column J Describe Proposed Solution If column G is noted as FM then describe how the product fully meets the requirement currently.
If column H is noted as C then describe the proposed configurable solution and approach to meet the requirement.
If column I is noted as CM then describe the proposed solution and approach to meet the requirement.
| Column K | Brand Name or equivalent Tool | List the name of the brand name or equivalent tool that will be used to satify the requirement |
| Column L | Module Name within the Tool | List the name of the module within the proposed tool that will be used to satify the requirement |
| Column M | Core Requirement | Indicates requirements that are needed for the system to go into initial production to FDA FAERS users. Production will occur at most 18 months after the start of the contract |
| Column N | Core Requirement schedule | Fillable colummn where offerors are to list the estimated number of months from start of the contract that core requirements will be implemented into FDA production environment. Note that this column will be blank for non-core requirements. The offeror shall indicate the estimated number of months (1-18) from start of contract to implement each core requirement listed in Column M tabs. All core requirements are expected to be implemented within 18 months |
Acronyms and Abbreviations
| ACRONYM/TERM | DESCRIPTION |
| AEPP | Adverse Event and Product Problems |
| AERPS | Adverse Events Reporting Programs Support |
| AERS | Adverse Event Reporting System |
| AERSPROD | Adverse Event Reporting System Production Database |
| AERSTEST | Adverse Event Reporting System Test Environment |
| API | Application Programming Interface |
| API | Active Product Ingredient |
| ASR | Alternative Summary Report |
| ASTD | American Society of Training and Development |
| ATO | Authority to Operate |
| BAER | Basal Adverse Event Report |
| BAU | Business as Usual |
| BLA | Biologics License Agreement |
| BO | Business Objects |
| BOM | Bill of Materials |
| BPDR | Biologic Product Deviation Report |
| BRD | Business Requirements Documents |
| BRMS | Business Rule Management System |
| C&A | Certification and Accreditation |
| CBER | Center for Biologics Evaluation and Research |
| CCB | Change Control Board |
| CMMI | Capability Maturity Model Integration |
| CDC | Centers for Disease Control |
| CDER | Center for Drug Evaluation and Research |
| CDRH | Center for Devices and Radiological Health |
| CFSAN | Center for Food Safety and Applied Nutrition |
| CM | Configuration Management |
| CMP | Configuration Management Plan |
| COTS | Commercial-Off-the-Shelf |
| CP | Core Processing |
| CPU | Central Processing Unit |
| CR | Change Request |
| CR | Clarification Request |
| CRP | Conference Room Pilot |
| CSO | Consumer Safety Officer |
| CSS | Consolidated Spreadsheet |
| CVM | Center for Veterinary Medicine |
| DADS | Developers and Distributors System |
| DAARTS | Document Archiving, Reporting and Regulatory Tracking System |
| DAR | Decision Analysis and Resolution |
| DBA | Database Administrator |
| DDRE | Division of Drug Risk Evaluation |
| DMETS | Division of Medication Errors and Technical Support |
| DQRS | Drug Quality Reporting System |
| DSC | Data Standards Counsel |
| E2B | International Conference on Harmonization's (ICH) Electronic |
| Transmission of Individual Case Safety Reports Message Specification format | |
| EDR | Electronic Document Room |
| EFS | Electronic File System |
| ES | Enterprise Search |
| ESG | Electronic Submissions Gateway |
| eSub | Electronic Submission |
| ETL | Extract, Transform, and Load |
| FACTS | Field Accomplishments and Compliance Tracking System |
| FAERS | FDA Adverse Event Reporting System |
| FAERSDEV | FDA Adverse Event Reporting System Development Database |
| FAR | Federal Acquisition Regulation |
| FAR | Field Alert Report |
| FDA | Food and Drug Administration |
| FDAAA | Food and Drug Administration Amendments Act |
| FDWG | FAERS Data Workgroup |
| FEDSIM | Federal Systems Integration and Management Center |
| FEI | Firm Established Identifier |
| FIPS | Federal Information Processing Standards |
| FISMA | Federal Information Security Management |
| FOIA | Freedom of Information Act |
| GOTS | Government Off-the-Self |
| GUI | Graphical User Interface |
| HCTP | Human Cell Tissue Products |
| HHS | Health and Human Services |
| HL7 | Health Level Seven |
| HLGT | High Level Group Term |
| HLT | High Level Term |
| IAW | In Accordance With |
| ICSR | Individual Case Safety Report |
| ICW | Interactive Courseware |
| ID | Identification |
| IDMP | Identification of Medicinal Product |
| ILT | Instructor Led Training |
| IND | Investigational New Drug |
| IP | Internet Protocol |
| IPD | Interactive Product Demonstration |
| IPT | Integrated Project Team |
| ISR | Individual Safety Report |
| ISSO | Information System Security Officer |
| ISSP | Information Systems Security Program |
| IT | Information Technology |
| JDBC | Java Database Connectivity |
| LDD | Lot Distribution Data |
| LMS | Learning Management System |
| LOE | Level of Effort |
| LOV | List of Values |
| MCN | Manufacturer Control Number |
| MEDDRA | Medical Terminologies |
| MOU | Memorandum of Understanding |
| MS | Microsoft |
| NDA | New Drug Application |
| NDC | National Drug Code |
| NIH | National Institutes of Health |
| NIST | National Institute of Standards and Technology |
| NME | New Molecular Entity |
| OCP | Office of Combination Products |
| O&M | Operations and Maintenance |
| ODC | Other Direct Cost |
| OIM | Office of Information Management |
| OND | Office of New Drugs |
| OOTB | Out of the Box |
| OPA | Oracle Pharmaceutical Application |
| ORA | Office of Regulatory Affairs |
| OSE | Office of Surveillance and Epidemiology (office under CDER) |
| PCR | Product Change Request |
| Portable Document Format | |
| PDM | Physical Data Model |
| PIA | Privacy Impact Assessment |
| PII | Personally Identifiable Information |
| PM | Project Management |
| PMP | Project Management Plan |
| POC | Point of Contact |
| PRR | Production Readiness Review |
| PSUR | Periodic Safety Update Report |
| PT | Preferred Term |
| PVCS | Polytron Version Control System |
| Q&A | Question and Answer |
| QA | Quality Assurance |
| QBE | Query by Example |
| R1 | Release One |
| R&D | Research and Development |
| RA | Risk Assessment |
| RDP | Remote Desktop Protocol |
| RFI | Request for Information |
| RFP | Request for Proposal |
| RQ | Rational Questionnaire |
| RTM | Requirements Traceability Matrix |
| SC | Security Categorization |
| SCORM | Sharable Content Object Reference Model |
| SDLC | System Development Lifecycle |
| SE | Safety Evaluator |
| SEI | Software Engineering Institute |
| SME | Subject Matter Expert |
| SMQ | Standard MedDRA Query |
| SMT | Senior Management Team |
| SOA | Service Oriented Architecture |
| SOP | Standard Operating Procedure |
| SOW | Statement of Work |
| SP | Special Publication |
| SPL | Structured Product Labeling |
| SRA | SRA International, Inc. |
| SRS | Systems Requirements Specification |
| SRS | Spontaneous Reporting System |
| SRP | Safety Reporting Portal |
| SSL | Secure Socket Layer |
| SSO | Single Sign-on |
| SSP | System Security Plan |
| TAS | Tracking and Accountability System |
| TBD | To Be Determined |
| TCB | Technical Control Board |
| TCP | Transmission Control Protocol |
| TMS | Thesaurus Management System |
| TOR | Task Order Request |
| UAT | User Acceptance Testing |
| VBA | Visual Basic |
| VPN | Virtual Private Network |
| V/S | Vigilance/Surveillance |
| WBS | Work Breakdown Structure |
| WBT | Web-Based Training |
| WHO | World Health Organization |
EB-Electronic Submission
| Req ID# | Description | Category | Sub-Category | Notes | Must Have | FM | C | CM | Describe Proposed Solution | Brand Name or Equal Tool | Module Name within the Tool | Core Requirement | Core Requirement Schedule | |
| EB1.0 | The system shall have the capability to accept electronic submissions of pre-market and post-market adverse event reports and product quality reports. | Electronic Submission | Not Applicable | Must Have | Core Requirement | |||||||||
| EB1.1 | The system shall have the capability to accept ICH E2B R2 xml submissions. | Electronic Submission | E2B R2 | Must Have | Core Requirement | |||||||||
| EB1.1.1 | The system shall have the capability to accept ICH E2B R2 xml submissions in a batch, based on the FDA Regional Technical Specifications. | Electronic Submission | E2B R2 | Must Have | Core Requirement | |||||||||
| EB1.1.2 | The system shall have the capability to generate an ICH E2B R2 xml with extended data fields based on the FDA Regional Technical Specifications for a single report or a batch of reports. | Electronic Submission | E2B R2 | Must Have | Core Requirement | |||||||||
| EB1.1.3 | The system shall have the capability to convert ICH E2B R2 xml to ICH E2B R3 xml based on the FDA Regional Technical Specifications and the ICH E2B backward and forward compatibility document. | Electronic Submission | E2B R2 | Must Have | Core Requirement | |||||||||
| EB1.2 | The system shall have the capability to accept ICH E2B R3 xml submissions. | Electronic Submission | E2B R3 | Must Have | Core Requirement | |||||||||
| EB1.2.1 | The system shall have the capability to accept ICH E2B R3 xml submissions in a batch, based on the FDA Regional Technical Specifications. | Electronic Submission | E2B R3 | Must Have | Core Requirement | |||||||||
| EB1.2.2 | The system shall have the capability to convert ICH E2B R3 xml to ICH E2B R2 xml based on the FDA Regional Technical Specifications and the ICH E2B backward and forward compatibility document. | Electronic Submission | E2B R3 | Must Have | Core Requirement | |||||||||
| EB1.2.3 | The system shall have the capability to generate an ICH E2B R3 xml with extended data fields based on the FDA Regional Technical Specifications for a single report or a batch of reports. | Electronic Submission | E2B R3 | Must Have | Core Requirement | |||||||||
| EB1.3 | The system shall have the capability to accept and store ICH E2B attachments. | Electronic Submission | E2B Attachments | Must Have | Core Requirement | |||||||||
| EB1.3.1 | The system shall have the capability to accept ICH E2B R2 xml submissions with only PDF attachments. | Electronic Submission | E2B Attachments | Must Have | Core Requirement | |||||||||
| EB1.3.2 | The system shall have the capability to accept ICH E2B R3 xml submissions with any type of attachments. | Electronic Submission | E2B Attachments | Must Have | Core Requirement | |||||||||
| EB1.3.3 | The system shall store the attachment to the Enterprise Search (Documentum based tool) systems with in FDA. | Electronic Submission | E2B Attachments | Must Have | Core Requirement | |||||||||
| EB1.3.4 | The system shall unprotect the attachment before storing it in Enterprise Search. | Electronic Submission | E2B Attachments | Must Have | Core Requirement | |||||||||
| EB1.3.5 | The system shall link the stored attachment to the report in FAERS II. | Electronic Submission | E2B Attachments | Must Have | Core Requirement | |||||||||
| EB1.4 | The system shall accept and process extended XML. | Electronic Submission | Extended XML | Must Have | Core Requirement | |||||||||
| EB1.4.1 | The system shall have the capability to configure and process additional data fields as extended XML to the standards ICH E2B data fields. | Electronic Submission | Extended XML | Must Have | Core Requirement | |||||||||
| EB1.4.2 | The system shall have the capability to configure the additional data fields during data import as extended data tags to the standards ICH E2B data fields | Electronic Submission | Extended XML | Must Have | Core Requirement | |||||||||
| EB1.4.3 | The system shall have the capability to accept and process ICH E2B R2 or ICH E2B R3 extended xml for the adverse event reports. | Electronic Submission | Extended XML | For e.g. Adverse event reports includes tissues, blood, drug, therapeutic biologic. Extended tags are required to accommodate the data variations between these product types. | Must Have | Core Requirement | ||||||||
| EB1.4.4 | The system shall have the capability to accept and process ICH E2B R2 or ICH E2B R3 extended xml for the product quality reports to accommodate Field Alert Reports, Biologic Product Deviation Report and MedWatch report. | Electronic Submission | Extended XML | For e.g. Product quality reports includes tissues, blood, drug, therapeutic biologic. Extended tags are required to accommodate the FARs and BPDRs. | Must Have | Core Requirement | ||||||||
| EB1.5 | The system shall perform data checks on the incoming ICH E2B R2 or ICH E2B R3 XML. | Electronic Submission | Data Check | Must Have | Core Requirement | |||||||||
| EB1.5.1 | The system shall have the capability to configure data checks that can be applied to the incoming ICH E2B R2 or ICH E2B R3 XML based on existing and future FDA defined data standards. | Electronic Submission | Data Check | For e.g. FDA defined data standards could be Regional technical specification for electronic submission or any additional checks identified by FDA | Must Have | Core Requirement | ||||||||
| EB1.5.1.1 | The system shall have the capability to add new data checks via configuration that can be applied to the incoming ICH E2B R2 or ICH E2B R3 XML data fields based on future FDA defined data standards and data quality rules. | Electronic Submission | Data Check | Must Have | Core Requirement | |||||||||
| EB1.5.1.2 | The system shall have the capability to update data checks via configuration that can be applied to the incoming ICH E2B R2 or ICH E2B R3 XML data fields based on exiting FDA defined data standards and data quality rules. | Electronic Submission | Data Check | Must Have | Core Requirement | |||||||||
| EB1.5.2 | The system shall have the capability for an administrator to turn ON edit checks via configuration. | Electronic Submission | Data Check | ON stands for making a data check active | Must Have | Core Requirement | ||||||||
| EB1.5.3 | The system shall have the capability for an administrator to turn OFF edit checks via configuration. | Electronic Submission | Data Check | OFF stands for making a data check inactive | Must Have | Core Requirement | ||||||||
| EB1.6 | The system shall sent acknowledgement to the sender of the report after processing. | Electronic Submission | Acknowledgement | Must Have | Core Requirement | |||||||||
| EB1.6.1 | The system shall have the capability to automatically send an acknowledgement of acceptance to the sender if the submitted reports comply with the FDA defined standards. | Electronic Submission | Acknowledgement | Must Have | Core Requirement | |||||||||
| EB1.6.2 | The system shall have the capability to automatically send an acknowledgement of rejection to the sender if the submitted reports do not comply with the FDA defined standards. | Electronic Submission | Acknowledgement | Must Have | Core Requirement | |||||||||
| EB1.7 | The system shall generate an ICH E2B R2 or R3 XML for data export. | Electronic Submission | Data Export | Must Have | Core Requirement | |||||||||
| EB1.7.1 | The system shall have the capability to search for reports based on criteria to generate ICH E2B R2 or R3 XML for data export. | Must Have | Core Requirement | |||||||||||
| EB1.7.2 | The system shall have the capability to configure the inclusion or exclusion of report data fields to generate an ICH E2B R2 or R3 XML for data export. | Electronic Submission | Data Export | Must Have | Core Requirement | |||||||||
| EB1.7.3 | The system shall have the capability to save different configuration of the inclusion and exclusion data fields to generate ICH E2B R2 or R3 xml for data export to different internal and external parties. | Electronic Submission | Data Export | For e.g. the configuration to generate data for WHO should be created once and saved. Subsequent sending will only entail retrieving the stored configuration. | ||||||||||
| There could be another configuration to generate data to send to other internal systems within FDA. | Must Have | Core Requirement | ||||||||||||
| EB1.7.4 | The system shall have the capability to generate XML files in ICH E2B R2 or R3 format in a batch. | Electronic Submission | Data Export | Must Have | Core Requirement | |||||||||
| EB1.7.5 | The system shall have the capability to place the generated ICH E2B R2 or R3 XML files in a folder specified for each receiver via configuration. | Electronic Submission | Data Export | Must Have | Core Requirement | |||||||||
| EB1.8 | The system shall archive the incoming ICH E2B R2 XML files received after successfully processing. | Electronic Submission | Archive XML | Must Have | Core Requirement | |||||||||
| EB1.8.1 | The system shall have the capability to archive the processed ICH E2B XML files in a specified network folder both for adverse event and product quality reports. | Electronic Submission | Archive XML | Must Have | Core Requirement | |||||||||
| EB1.8.2 | The system shall have the capability to archive the acknowledgement generated after processing an ICH E2B XML files in a specified network folder both for adverse event and product quality reports. | Electronic Submission | Archive XML | Must Have | Core Requirement | |||||||||
| EB1.9 | The system shall have the capability to manage electronic submission. | Electronic Submission | Manage Electronic Submission | Must Have | Core Requirement | |||||||||
| EB1.9.1 | The system shall have the capability for an administrator to view the documented actives performed on each incoming ICSR xml that were processed. | Electronic Submission | Manage Electronic Submission | For e.g. Display may include sender of the report, the actual incoming XML, date and time received, date and time processed, result of the processing, the outgoing acknowledgement, data and time acknowledgement sent to sender and case id if processing successful. | Must Have | Core Requirement | ||||||||
| EB1.9.2 | The system shall have the capability to retrieve archived ICH E2B R2/R3 XML and reprocess through system on demand. | Electronic Submission | Manage Electronic Submission | Must Have | Core Requirement | |||||||||
| EB1.9.3 | The system shall have the capability to process a batch of incoming ICH E2B R2/R3 XML files. | Electronic Submission | Manage Electronic Submission | Must Have | Core Requirement | |||||||||
| EB1.9.4 | The system shall have the capability to not reject the entire batch if some reports in the batch were rejected. | Electronic Submission | Manage Electronic Submission | If a batch has 10 reports and 2 were rejected then accept the 8 reports with positive acknowledgement and reject the 2 reports with negative acknowledgement. | Must Have | Core Requirement | ||||||||
| EB1.9.5 | The system shall have the capability to configure the export location for placing the generated ICH E2B R2 or R3 format report for other office/center from the case processing work flow or on demand. | Electronic Submission | Manage Electronic Submission | Must Have | Core Requirement | |||||||||
| EB1.9.6 | The system shall have the capability to support multiple DTD to validate different types of ICH E2B R2 xml submissions. | Electronic Submission | Manage Electronic Submission | For e.g. Receiving reports for different product types may require to accommodate the data variations between these product types. | Must Have | Core Requirement | ||||||||
| EB1.9.7 | The system shall have the capability to handle large amount of submissions. | Electronic Submission | Manage Electronic Submission | FDA receives about 4000 per day with a growth rate of 15% per year. | Must Have | Core Requirement | ||||||||
| EB1.9.8 | The system shall have the capability to automatically create multiple threads to process when large amount of submission are received. | Electronic Submission | Manage Electronic Submission | Must Have | Core Requirement | |||||||||
| EB1.9.9 | The system shall have the capability to send alerts to the administrator if processing is interrupted for any reason. | Electronic Submission | Manage Electronic Submission | Must Have | Core Requirement | |||||||||
| EB1.9.10 | The system shall have the capability to upload electronic ICSRs that were submitted in ICH E2B R2 format via physical media and process them. | Electronic Submission | Manage Electronic Submission | A company sends the XML files in a physical media (e.g. CD, DVD) as their Gateway is down. The system should be able to upload the XML files and process them. | Must Have | Core Requirement | ||||||||
| EB1.9.11 | The system shall have the capability to upload ICSR attachments that were submitted in ICH E2B R2 format via physical media and process them. | Electronic Submission | Manage Electronic Submission | A company sends the ICSR attachments files in a physical media (e.g. CD, DVD) as their Gateway is down. The system should be able to upload the ICSR attachments files and process them. | Must Have | Core Requirement | ||||||||
| EB1.9.12 | The system shall have the capability to upload electronic ICSRs that were submitted in ICH E2B R3 format via physical media and process them. | Electronic Submission | Manage Electronic Submission | Must Have | Core Requirement | |||||||||
| EB1.10 | The system shall provide a tool for E2B (R2) & (R3) XML file parser and validator to external users (i.e. industry). | Electronic Submission | XML File Parser/Validator | Industry users (reporters) must validate their ICSR E2B R2 & R3 XML file prior to submission to FDA. | Must Have | Core Requirement | ||||||||
| EB1.10.1 | The system shall enable open users access via internet browsers. | Electronic Submission | XML File Parser/Validator | Firefox, Internet Explorer, Google Chrome | Must Have | Core Requirement | ||||||||
| EB1.10.2 | The system shall enable an open access to all industry users to validate ICSR XML files prior to the submission to FDA. | Electronic Submission | XML File Parser/Validator | Firefox, Internet Explorer, Google Chrome | Must Have | Core Requirement | ||||||||
| EB1.10.3 | The system shall enable open users to process ICSR E2B (R2 & R3) XML files in bulk or batch. | Electronic Submission | XML File Parser/Validator | Batch processing for all ICSRs prior to submission | Core Requirement | |||||||||
| EB1.10.4 | The system shall provide upload functionality to validate XML files. | Electronic Submission | XML File Parser/Validator | Upload for XML validation processing | Must Have | Core Requirement | ||||||||
| EB1.10.5 | The system shall generate messages like warning, caution, rejection after the validation processing. | Electronic Submission | XML File Parser/Validator | Warning Messages, Caution Messages and Rejection Messages | Must Have | Core Requirement | ||||||||
| EB1.10.6 | The system shall display all messages in XML format in the internet browsers. | Electronic Submission | XML File Parser/Validator | Must Have | Core Requirement | |||||||||
| EB1.10.7 | The system shall enable open users to download all XML messages. | Electronic Submission | XML File Parser/Validator | Industry users (reporters) can download all message for edit purpose into their internal Pharmacovigilance tools. | Must Have | Core Requirement | ||||||||
| EB1.10.8 | The system shall validate the ICSR E2B (R2 & R3) XML files against the defined XML schema or DTD. | Electronic Submission | XML File Parser/Validator | XML Schema or DTD referenced from ICH defined guidelines | Must Have | Core Requirement | ||||||||
| EB1.10.9 | The system shall able to convert the ICSR E2B (R2) XML to E2B (R3) XML prior to XML schema validation. | Electronic Submission | XML File Parser/Validator | Convert E2B (R2) to E2B (R3) XML | Must Have | Core Requirement | ||||||||
| EB1.10.10 | The system shall validate XML syntax in case the XML schema or DTD is not compatible with the XML file uploaded. | Electronic Submission | XML File Parser/Validator | Only syntax check performed if XML schema or DTD is not mentioned in the XML file header or not compatible. | Core Requirement | |||||||||
| EB1.10.11 | The system shall enable open users to paste the copied XML data into a screen field for validation. | Electronic Submission | XML File Parser/Validator | Copy and Paste your XML document | Core Requirement | |||||||||
| EB1.10.12 | The system shall provide the help file describing "how to validate your XML files (including reference XML Schema or DTD)". | Electronic Submission | XML File Parser/Validator | Help file for ICH defined XML Schema or DTD and How to use it. | Must Have | Core Requirement | ||||||||
| EB1.10.13 | The system shall provide a smart fix features with automatic error correction. | Electronic Submission | XML File Parser/Validator | Automatic correction for identified warning, caution and/or rejection messages | Core Requirement | |||||||||
| EB1.10.14 | The system shall provide an easy validator window or screen for troubleshooting and error reporting. Refer to EB1.10.5, EB1.10.6, EB1.10.7 and EB1.10.11 | Electronic Submission | XML File Parser/Validator | Must Have | Core Requirement | |||||||||
| EB1.10.15 | The system shall provide links to error in working XML files and associated schema or DTD definition. | Electronic Submission | XML File Parser/Validator | Must Have | Core Requirement | |||||||||
| EB1.10.16 | The system shall provide search functionality in the validation window or screen. | Electronic Submission | XML File Parser/Validator | Must Have | Core Requirement | |||||||||
| EB1.10.17 | The system shall validate country specific listed items in the ICSR E2B (R2) & (R3) files. | Electronic Submission | XML File Parser/Validator | If reporter wants to submit the report to USA FDA then relevant items required for FDA must be validated, rest of the items should be ignored. Simliar rule applied to other regulatory agencies around the world. i.e. PMDA, Health Canada, EU, India FDA, China FDA etc. | Core Requirement |
DM-Dictionary Management
| Req ID# | Requirement Description | Functional Category | Functional Sub-Category | Notes | Must Have | FM | C | CM | Describe Proposed Solution | Brand Name or Equal Tool | Module Name within the Tool | Core Requirement | core requirement schedule | |
| DM2.0 | The system shall support multiple dictionaries i.e. product dictionary, adverse event dictionary and manufacturer dictionary that includes processing of post-market, pre-market and product quality reports. | Dictionary Management | Not Applicable | Must Have | core requirement | |||||||||
| DM2.0.1 | The system shall enable user to search dictionary attribute terms in the dictionaries. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.2 | The system shall enable user to view dictionaries and related reference tables. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.3 | The system shall enable authorized user to create or edit dictionary data fields. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.4 | The system shall enable authorized user to delete dictionary data fields. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.5 | The system shall enable authorized user to archive dictionary data fields. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.6 | The system shall enable authorized user to export dictionary data fields. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.7 | The system shall enable authorized user to print dictionary data fields. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.8 | The system shall enable authorized user to view history (i.e. audit logs - date, time and user name) dictionary data fields. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.9 | The system shall enable authorized user to drag and drop dictionary data items during the edit task. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.0.10 | The system shall enable authorized user to import dictionary related data items from multiple files. | Dictionary Management | Not Applicable | Must Have | Core Requirement | |||||||||
| DM2.1 | The system shall support FAERS Manufacturing Dictionary that includes list of organization, manufacturer and firm establishment. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.1 | The system shall provide key information related to organization or manufacturer. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.2 | The system shall enable authorized user (i.e. dictionary administrator) to add organization/manufacturer information to the FAERS manufacturer dictionary. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.3 | The system shall enable user to import organization/manufacturer information from the following sources. | |||||||||||||
| i.e. Establishment List in eList - Structured Product Labelling (SPL), Party and Party Addresses from DAARTS (CDICT schema) | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | ||||||||||
| DM2.1.4 | The system shall import organization/manufacturer information from data sources described in Requirement Number# DM2.1.3 automatically using an automated method. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.5 | The system shall import NDC Labeler Code organization/manufacturer information from the data sources defined in Requirement Number# DM2.1.3. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.6 | The system shall import FEI number organization/manufacturer information from the data sources defined in Requirement Number# DM2.1.3. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.7 | The system shall import DUNS number organization/manufacturer information from the data sources defined in Requirement Number# DM2.1.3. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.8 | The system shall notify FAERS dictionary administrator of the newly added manufacturer to quality check (QC) for use. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.9 | The system shall allow the FAERS dictionary administrator to manually create an organization/manufacturer to the FAERS manufacturer dictionary for coding purposes if these types of organization/manufacturer are listed on the submitted adverse event reports. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.10 | The system shall display an alert if a new organization/manufacturer being added already exists in the FAERS product dictionary. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.11 | The system shall check to see if a new organization/manufacturer being added from eList already exists in the FAERS product dictionary by attempting to match sequentially to the following criteria: | |||||||||||||
| Firm/Site Name, Firm/Site Legal Name, Firm/Site DUNS Number, Firm/Site FEI Number, and Firm/Site NDC Number | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | ||||||||||
| DM2.1.12 | The system shall enable FAERS dictionary administrator to enter a minimum set of organization/manufacturer information (Parent Company, Firm/Site Name and Firm Status) when manually adding a new organization/manufacturer to the manufacturer dictionary. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.13 | The system shall display a message notifying the FAERS dictionary administrator of the required minimum set of organization/manufacturer information that is not entered. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.14 | The system shall enable FAERS dictionary administrator to deactivate an added organization/manufacturer manually. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.15 | The system shall enable FAERS dictionary administrator to provide a reason when an organization/manufacturer is deactivated. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.16 | The system shall enable FAERS dictionary administrator to activate the new organization/manufacturer information from eList (SPL) after deactivating the existing organization/manufacturer entered manually. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.17 | The system shall enable FAERS dictionary administrator to update organization/manufacturer information to the FAERS manufacturer dictionary. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.18 | The system shall automatically update key organization/manufacturer information within 24 hours of a change that has occurred in the eList system. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.19 | The system shall notify FAERS dictionary administrator of the conflict details whenever there is a conflict (mismatch) between existing FAERS organization/manufacturer information and the updated information from eList. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.20 | The system shall notify FAERS dictionary administrator of organization/manufacturer information changes in the dictionary. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.21 | The system shall enable FAERS dictionary administrator to update cases associated with a sender organization and/or labeler manufacturer when the organization/manufacturer information changes in the manufacturer dictionary. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.22 | The system shall store the organization/manufacturer information in the dictionary in a hierarchical manner. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.23 | The system shall identify and notify the FAERS dictionary administrator if the organization/manufacturer is entered and is not linked in the hierarchy. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.24 | The system shall maintain the hierarchy structure of the parent child relationship when the parent in the hierarchy structure is changed. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.25 | The system shall provide the option to add or remove levels within the hierarchy. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.26 | The system shall audit all changes to the organization/manufacturer information in the dictionary. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.27 | The system shall display all organization/manufacturer information changes in the dictionary’s change history. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.28 | The system shall maintain an audit trail of all organization/manufacturer information changes and FDA hierarchical assignment changes. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||||||||
| DM2.1.29 | The system shall support Manufacturers dictionary with three levels. i.e. |
a. Group term (Pfizer)
b. Manufacturer Name (includes company characteristics)
| c. Verbatim terms (Pfizer ink) | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||
| DM2.1.30 | The system shall enable authorized user to “retire” names on the Verbatim and Group level. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | ||
| DM2.1.31 | The system shall enable user with advance interactive mode to drag and drop to move group terms under another group. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | ||
| DM2.1.32 | The system shall enable users the capability to “paint” collections of verbatim names and move them to a different group using interactive mode of drag and drop. | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | ||
| DM2.1.33 | The system shall enable user to view the following Firm category attributes: |
Firm/Site Name Firm/Site Address Firm/Site FEI number Firm/Site DUNS number Parent Company Name Parent Company Address Parent Company FEI
| Firm Function (Manufacturer, Distributor, etc.) | Dictionary Management | Manufacturer Dictionary | Must Have | Core Requirement | |||
| DM2.2 | The system shall support FAERS Product Dictionary, WHO-DD, and IDMP. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||
| DM2.2.1 | The system shall enable FAERS dictionary administrator to manually add new product (including non CBER/CDER regulated products such as dietary supplements or devices) identified in the World Health Organization Drug dictionary or other reference source to the FAERS product dictionary. | ||||||
| Note: The addition of non CBER/CDER regulated products is necessary for coding purposes if these types of products are listed on submitted adverse event case reports. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | |||
| DM2.2.2 | The system shall alert authorized user if a duplicate product exist during the new product addition with following matching values: | ||||||
| 1) Proprietary Name (trade name), 2) Active ingredient, 3) Firm Name, and 4) Synonym list (e.g. consider that the reported product name may be a misspelling of a valid proprietary or active ingredient name) | Dictionary Management | Product Dictionary | Must Have | Core Requirement | |||
| DM2.2.3 | The system shall enable FAERS dictionary administrator to override a manually entered data by other authorized user. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||
| DM2.2.4 | The system shall alert user requiring override by the FAERS dictionary administrator if product information already exists for a product being manually entered. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||
| DM2.2.5 | The system shall enable authorized user to update product information into the FAERS Product Dictionary. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||
| DM2.2.6 | The system shall enable authorized user to delete product information into the FAERS Product Dictionary. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||
| DM2.2.7 | The system shall enable authorized user to archive/deactivate product information into the FAERS Product Dictionary. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||
| DM2.2.8 | The system shall support an automated process to ETL (i.e. extraction, transformation, and load) from eList (SPL) product information into FAERS Product Dictionary (FPD). | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||
| DM2.2.9 | The system shall support key product information available in eList (SPL). |
Please see note section for list of product related attributes but these attributes are just a snapshot i.e. not limited. Dictionary Management Product Dictionary 1. Product Type
2. Active and Inactive Ingredient
3. UNII and BDNUM Identifier
4. Active Ingredient(s)*
5. Product Active Ingredient(s)*
6. Active Moiety*
7. Marketing Category (e.g., Application #, Monograph Citation, etc.)
8. Center (CBER or CDER)
9. Container size
10. Dosage Form (e.g., capsule or injection)
11. Firm Function (Re-Packager, Distributor, Labeler, Manufacturer)
12. Firm Name
13. Inactive Ingredient Name(s)
14. Indications and Usage
15. Lot number
16. Product Type (Human Prescription Drug, Human OTC)
17. Marketing Status (e.g., active or discontinued)
18. Product ID (contains the first two segments of the NDC [Labeler and product code])
19. National Drug Code (NDC)
20. Nonproprietary Name (usually the active ingredient or established name)
21. Package Description (e.g., vial, blister pack)
22. Pharmacologic Class* (two systems, NDF-RT from SPL and separately Anatomical Therapeutic Chemical (ATC) Classification)
23. Proprietary Name (also known as trade name)
24. Proprietary Name Suffix (such as extended release)
25. Route of Administration
26. Source * ( FDA or World Health Organization DD or Other Reference)
27. Strength
28. Strength Unit (mg or mL)
29. US or foreign marketed product (if marketing category = export only, then foreign product)
30. Synonym (this field does not come from SPL/eList) (e.g., ascorbic acid for Vitamin C)
31. Combination Product flag (this field does not come from SPL/eList) (defined as cross-Center-regulated products such as Drug + Device, etc.) Product/Combination Product (Yes
32. Proprietary Name (also known as trade name)
33. Proprietary Name Suffix (such as extended release)
34. Route of Administration
35. Source * ( FDA or World Health Organization DD or Other Reference)
36. Strength
37. Strength Unit (mg or mL)
38. US or foreign marketed product
| * denotes required field | Must Have | Core Requirement | |||||||
| DM2.2.10 | The system shall enable authorized user to browse/search the World Health Organization Drug Dictionary for product information. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.11 | The system shall enable authorized user to "copy and paste" or "drag and drop", multiple product attributes from external reference sources (including World Health Organization Drug Dictionary) to the FAERS product dictionary. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.12 | The system shall enable authorized user to enter a minimum set of product information when manually adding a new product to the product dictionary. See notes section | Dictionary Management | Product Dictionary | The minimum set of product information: | |||||
| Pharmacologic Class, Active Moiety, Active Ingredient(s), Product Active Ingredient(s), and Source | Must Have | Core Requirement | |||||||
| DM2.2.13 | The system shall enable authorized user to enter minimal key product information when manually adding a product. Refer to the Requirement Number# DM2.2.12 | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.14 | The system shall alert authorized user of the required minimum set of product information that is not entered. Refer to the Requirement Number# DM2.2.13 | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.15 | The system shall require authorized user to provide a reason when a product is deactivated. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.16 | The system shall enable authorized user to activate the new product information from SPL after deactivating the existing product sourced from an external reference. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.17 | The system shall automatically update key product information within 24 hours of a change that has occurred in the eList (SPL) system. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.18 | The system shall enable authorized user to receive a report of all the changes on a weekly basis to approve the product updates from SPL. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.19 | The system shall update product attributes (non-key product information) overwrite only the key product information fields that have changed in eList (SPL). Refer to the Requirement Number# DM2.2.18 | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.20 | The system shall alert authorized user whenever there is a conflict (mismatch) between existing FAERS product information and the updated information from SPL. Refer to the Requirement Number# DM2.2.19 | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.21 | The system shall display newly available SPL data for products that were manually added by the authorized user. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.22 | The system shall notify via email or alert to the authorized user of product information changes in the dictionary. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.23 | The system shall enable authorized user to update cases associated with a product when the product information changes in the product dictionary. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.24 | The system shall display product changes in all pharmacologic classes that the product is assigned to (if the product is assigned to more than one pharmacologic class). | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.25 | The system shall enable user to view the products under the updated hierarchy structure when the structure has changed. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.26 | The system shall automatic update the WHO-DD (World Health Organization Drug Dictionary) files in the FAERS Product Dictionary World Health Organization-Drug Dictionary browser at least quarterly. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.27 | The system shall enable authorized user to reconcile WHO-DD dictionary updates received by FDA with existing WHO-DD dictionary products in the FAERS product dictionary. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.28 | The system shall automatically flag products as "multiple ingredient products" for those products having more than one active ingredient. | Dictionary Management | Product Dictionary | Example: ACETAMINOPHEN\ASCORBIC ACID\DIMETHINDENE MALEATE\TROXERUTIN | Must Have | Core Requirement | |||
| DM2.2.29 | The system shall enable authorized user to flag products as "combination product" for those products with more than one product type (e.g., device/drug) | Dictionary Management | Product Dictionary | Example: BEXXAR Tositumomab and Iodine I 131 Tositumomab | Must Have | Core Requirement | |||
| DM2.2.30 | The system shall list the established pharmacologic class assignment for all products in the FAERS product dictionary when applicable. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.31 | The system shall enable authorized user to select an established pharmacologic class when manually adding a new product. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.32 | The system shall enable authorized user to manually add a pharmacologic class to the FDA-defined hierarchical structure in the product dictionary only when an existing pharmacologic class is not available. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.33 | The system shall enable authorized user to add new pharmacologic classes that are approved by a designated work group. | ||||||||
| Note: SPL will provide an interim pharmacologic class for products without an assigned pharmacologic class. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | |||||
| DM2.2.34 | The system shall enable authorized user to assign a pharmacologic class for products without an assigned pharmacologic class. | ||||||||
| Note: SPL will provide an interim pharmacologic class for products without an assigned pharmacologic class. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | |||||
| DM2.2.35 | The system shall automatic update product pharmacologic classes when the new product SPL is received. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.36 | The system shall require that all products, including those from an internal (FDA) data source and external data source must be assigned to one or more pharmacologic classes. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.37 | The system shall notify authorized user if a FDA regulated product is entered but not assigned to at least one pharmacologic class. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.38 | The system shall maintain the hierarchy structure of the parent child relationship of the pharmacologic class when the parent in the hierarchy structure is changed. | Dictionary Management | Product Dictionary | Must Have | Core Requirement | ||||
| DM2.2.39 | The system shall maintain the FAERS product dictionary with the FDA-defined hierarchy structure. See notes | Dictionary Management | Product Dictionary | FDA-defined hierarchy structure: Pharmacologic Class, Active Moiety, Active Ingredient, Product Active Ingredient(s), Proprietary Name | Must Have | Core Requirement | |||
| DM2.2.40 | The system shall enable authorized user to add or remove levels within the product hierarchy. See notes | Dictionary Management | Product Dictionary | Example: adding a new therapeutic classification system, or a lower level of an existing classification system (e.g.. ATC5 in stead of ATC4) | Must Have | Core Requirement | |||
| DM2.2.41 | The system shall enable authorized user to group products at a level between the proprietary name and active ingredient. | Dictionary Management | Product Dictionary | This functionality will assist users World Health Organization need to identify a subclass of proprietary name products such as all the Children’s Tylenol products. | Must Have | Core Requirement |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it.