Data Intake Process Flow

This section describes an end-to-end processing flow of files coming through the insurance carrier's interface to OIPA Data Intake (Data Intake Client) to OIPA.

Note:

1. For information on developing an interface to OIPA Data Intake (Data Intake Client), see the OIPA Data Intake Client Developer manual. This is normally a part of the OIPA implementation project that analyses the interfaces into OIPA and would need specific design for each interface. The Data Intake Client interface would be specially used to feed group data into OIPA for automated enrollment and billing.

2. This section may not contain all of the requirements for intake file processing. More detail is provided in subsequent sections in this document.

  1. The insurance carrier's interface to OIPA Data Intake (Data Intake Client) will send all family neutral records (JMS Messages) to OIPA for processing. The data intake client will submit the file header, including a unique file identifier, group customer number, expected record count, and the intake profile name. The intake profile name is used to look up the file processing configuration for the file. As the number of records can be rather large, the file will remain in a "Loading" status in OIPA until all of the records have been received.

    1. If the file is a TPA / Multi-Customer File, the insurance carrier's data intake client will segregate each group customer into separate files for submission to OIPA.

    2. The insurance carrier's data intake client will also send additional file details to OIPA for purposes of reporting and processing. For example, the data intake client will send the number of records that failed with fatal errors to OIPA. That information will be made available on the Intake File screen in OIPA, and will also be available to configuration for purposes of threshold processing.

    3. In case of large files which can take considerable amount of time for loading, a file can also be split into multiple files and enable parallel loading/processing. But this is applicable only for files with independent records (messages) and not family/dependent records. This parallel processing can be enabled by a JMS message property (independent="Y/N") which will be part of Begin Loading message. For more information of message properties, please refer to Data Intake Client Developer Manual.

  2. The insurance carrier's data intake client will then load all of the Family Neutral records that it compiled into OIPA. Each record will contain identifying information, including the sponsor id, the unique identifier of the file the record belongs to, and the family neutral XML data. Each record corresponds to a member of the Group Customer. It contains the sponsor / employee information, as well as dependent information. It is expected that the data intake client will submit all family neutral records, including those that have errors, in order to allow OIPA to properly run validations. Each Family Neutral Record is comprised of a series of records containing information pertaining to a member belonging to a particular Sponsor. Each Record in a Family Neutral Record will be processed in the order that it is provided to OIPA. The order of processing is determined by the insurance carrier's data intake client.

  3. Once all of the records have been loaded, the insurance carrier's data intake client will indicate to OIPA that the file is finished loading. OIPA will update the status of the file to "Pending".

  4. The insurance carrier's data intake client will submit a Process File request to OIPA, sending in the unique file identifier, to indicate that processing can begin for the file.

  5. OIPA will look up the Data Intake Profile for the file to determine the preferences and other fields, as well as the configuration that will be used to process the file. Using the configuration, OIPA will prepare the file for processing.

    1. If File Comparison is configured in the Data Intake Profile for the file, OIPA will run file level comparisons by comparing the incoming file to the last successfully processed file that was received for the same Data Intake Profile. If any records are missing in the new file, empty records will be created and associated with the new file, the records will be marked as "Removed from File".

    2. OIPA will update the file to a "Pre Processing" status, as well as update all records to a "Pending Pre-Processing" status, which queues the file and records for processing in OIPA.

  6. All records within a FNR are processed together, in the order that was specified when the records were created in OIPA. The record with the lowest process order is processed first. Each record in the FNR runs through the pre-processing configuration attached to the Data Intake Profile. The following steps describe a scenario for pre-processing of each record in the FNR:

    1. Validate the Fields in the record. If any fields fail validation, the field will be marked as having a validation error.

    2. Calculate changes for the record.

      1. If file comparison is enabled, look up the last family neutral record processed for this member and intake profile. Compare the current record to the last record and calculate the changes.

      2. If system comparison is enabled, load the field data from the OIPA database. Compare the current record to the system data and calculate the changes.

      3. If there is more than one record pertaining to the same member in an FNR, only the first record will be compared to system state. Subsequent records for the same member in the same FNR and file will be compared to the prior record in the FNR.

    1. Execute math to perform calculations and generate the map of activities (the Activity Sequence Process) that need to be run in the system.

    2. Execute business rules for the record.For example, Cross field validations can be exercised in math, and fail in the Validate Expressions.

    3. Blocking Rules will be consulted to determine if other records in the FNR can continue processing when an error is incurred.

    4. Store the Activity Sequence Process in the system, as well as any additional data that was set while running the pre-processing configuration. For example, the Record may be marked as an "Auto Cancel". That information would be persisted to the system.

    5. Move the record to a "Pending Validation" status if it is not a fatal error.

  7. After all of the records have been pre-processed, the File Level Processing will be run to determine if the file can be executed. At the File Level, the following processing occurs:

    1. Calculate statistics in Math for the file using the File level transaction.

    2. Run validations to determine if any thresholds failed.

    3. Update File Level information to store the statistics and other data for reporting purposes.

    4. Depending on the outcome of file level validation, the file processing could be halted and an error message sent to the insurance carrier. In this event, the File will be marked as error, and the activities that were generated in pre-processing will not be executed, the file will not continue processing.

  8. Once the File passes validation, OIPA will prepare the file for Execution. All of the records marked as "Changed", "New to File", or "Removed from File" will be updated to a "Pending Execution" status, and the status of the file will be marked as "Executing". This will schedule the file for execution in the OIPA Grid.

  9. All records within a family neutral record are processed together, in the order that was specified when the records were created in OIPA. The record with the lowest process order is processed first. All of the activities for each record will be processed before moving onto the next record in the FNR.

    1. If any record within an FNR fails for any reason during activity processing, blocking rules will be consulted to determine if records can continue processing in the FNR.

      1. If an error has occurred on the primary member / sponsor, then processing will halt for all of the subsequent records for this FNR. Those records will be updated to have a "Blocked" status.

      2. If an error has occurred on a dependent record, then processing will halt for subsequent records in the FNR pertaining only to that dependent that failed. Those records will be updated to have a "Blocked" status.

    1. After activities are executed for each record in the FNR, the record is updated to an "Active" status.

  10. Once all of the Records in a file have been executed, the File will complete processing in OIPA. The File record in the database will be updated with the status and any other information relevant to the processing of the file. Once the file is complete, it will be saved in a "Complete" status.