Use the Follow-up Receive Tab

The Follow-up Receive tab enables you to configure the configuration attributes for the ICSR profile that are specific for the Follow-up imports of the ICSR file. This tab is available for R3 based ICSR profiles that support the import (currently applicable for EMA and PMDA (R3)).

To configure the validations rule against the ICSR element, following fields have been made available to user under the Follow-up Receive tab:

Field	Type	Description
ICSR Follow-up case identification logic	Text Area	Profile level logic to identify the Follow-up case against the incoming ICSR. OOTB default logic: Current Argus embedded logic
Custom comparison logic	Text Area Default : Blank	Profile level option to specify the logic to customize the OOTB PK driven Difference report data such that user can define a PL/SQL block with this section to control the Difference report data that will be further used during the case acceptance. The order of execution for the Custom logic is that, first all the embedded OOTB system logic to build the comparison data are executed with application of Default deletes, and then once the embedded logic for Difference report execution is completed the configured custom comparison logic is invoked and the result of that custom logic is reflected on the difference report UI and further will be consumed during case data acceptance. The Configured custom logic is executed under the same DB user level access right as application does for import mapping SQL logic. Validate that under the same access right user is able to update, insert and delete the data of the Difference report table. Any changes to the custom logic are audit logged and are supported in the copy profile and print as well. Application provides all the possible Bind variable that this custom logic would require in order to define the business specific logic.
PK Element configuration	Download (Button)	This button facilitates the user to configure the PK's for identifying the repeater records in the ICSR file, so that those can be used while building the Difference report such that, if for a repeater record the configured PK elements are same in the incoming ICSR and the ICSR from the Case data then that record shall be treated as the same record. On clicking of the Download button application will export a CSV file with all the PK's for that profile as per the attached sample.
PK Element configuration	Upload (Button)	On clicking the upload button the standard Argus upload dialogue appears with fowling title and label: Title: ICSR Mapping Utility Label: ICSR PK Element Configuration Allowed File Types: CSV As soon as user uploads the CSV file with the application executes a validation over the uploaded file to in order to validate that the uploaded CSV file is as per the application expectations. Profile: column lists only the name of the profile for which file is getting uploaded. In case of any mismatch an error is pushed into Val_error column (<Profile Name> is different than the current profile). PARENT_ELEMENT: The data in this column is validated to list down only those elements which have child elements to them in the current profile. In case of any incorrect entry an error is pushed into Val_error column (<Parent Element> is not a valid Parent element as per the current profile). DTD_ELEMENT: The data in this column is validated to list down only those elements are true child elements i.e. they are the exact root node of the xml. In case of any incorrect entry an error is pushed into Val_error column (<DTD Element> is not a valid Child element as per the current profile). DTD_ELEMENT: The data in this column is validated that the elements belongs to the Parent element as per the current profile. i.e. DRUGCHARACTERIZATION - Parent element is "DRUG" as per the EMA R3 OOTB Profile whereas in the uploaded CSV the parent for the same is mentioned as DRUGINDICATIONR3 then the error is pushed to the VAL_Error column (<DTD Element> doesn't belong to <Parent Element> as per the current profile).
PK Element configuration	Upload (Button)	DEFAULT_DELETE: The data in this column is validated to see if it contains any value other than "Y" or "N". Where "Y" denotes that the repeater element will be marked for Deletion by default in case of no match with the incoming file. And "N" denotes that the repeater block will not be marked for deletion by default. In case of any other value in the columns the error is pushed to the VAL_Error column (Incorrect value. Value should be either "Y" or "N"). DEFAULT_DELETE: The data in this column is validated to see the same value exist for all the rows for a particular PARENT_ELEMENT i.e. for all the rows for a particular parent element the value for DEFAULT_DELETE should be same. In case of validation failure the error is pushed to the VAL_Error column (All the values corresponding to <PARENT_ELEMENT> should be same). None of the four columns "PROFILE", "PARENT_ELEMENT", "DTD_ELEMENT" & "DEFAULT_DELETE" are blank for either of the row. In cases any of them is blank the error is pushed to the VAL_ERROR column(<Column Name(comma separated)> cannot be blank). As soon as user upload the CSV file all the above validation is executed and in case there are any errors the file with the error listed in VAL_ERROR column is pushed to user from the browser (all these operations shall be performed within the upload user action). Also, if there are any validation errors the uploaded file data is not reflected into the DB configurations i.e. only a file without any validation errors can be committed to DB. All the changes to the PK's are audit logged. The VAL_ERROR column is only present in CSV file only when there are any errors to the uploading file. It is not be present in the normal downloaded or uploaded file.