Inbound Processing Discrepancy

Healthcare Integrations (automated data exchanges between healthcare-related source systems and ORMB) routinely move many records through an inbound message queue. In such kind of setup, the time ORMB system receives an inbound message may differ from the time the source system created the original record.

When multiple messages reach the ORMB system at nearly the same time, relying only on ORMB creation timestamp may process those inbound messages based on the arrival timing instead of the order in which they were created in the source system. To counter such scenario, the Pricing Discrepancy design resolves this issue by storing the source system transaction timestamp in the inbound message record. The goal is to process batch records in the most accurate available time sequence, while using a consistent fallback whenever timestamps are missing or identical.

Timing Distinctions - Driving the Design

The system design maintains two timestamps, each serving a distinct purpose. The CRE_​DTTM column continues to store the system date, whereas the newly introduced TXN_​DTTM column stores the exact timestamp when the inbound message is created in the source system. For instance, if Person A is created in the source system on 01 August 2026 at 09:00:00 A.M. and Person B is created on the same day at 09:15:00 A.M., and the source system creates a single inbound message for both the persons on the same day at 09:30:00 A.M., where that inbound message arrives in the ORMB application at 09:45:00 A.M. Now, in this scenario, the system does the following:

  • Stores the date and time as 01 August 2026, 09:30:00 A.M. in the TXN_​DTTM field.

  • Stores the date and time as 01 August 2026, 09:45:00 A.M. in the CRE_​DTTM field.

Capturing both values makes the difference explicit and preserves the existing system record.

Design Level Changes

The following design level changes are done in the ORMB application:

Column/Parameter Action/Purpose

Table: C1_​INBOUND_​MESSAGE

Column: TXN_​DTTM

Data type: TIMESTAMP(6)

The new TXN_​DTTM column stores the precise point in time, combining both a calendar date and clock time.

Note:
If the TXN_​DTTM contains NULL in the inbound message, system stamps the System Date in the TXN_​DTTM column.

Batch: C1-HCEXS (HC Inbound Message Monitor Process)

Batch Parameters:

  • externalSourceId

  • inboundMessageType

  • The externalSourceId parameter filters the inbound messages based on the specified external source ID. Only inbound messages with a matching externalSourceId are selected for processing. The externalSourceId parameter is defined as a String. It filters the inbound messages on the C1_​EXT_​SOURCE_​ID column of the C1_​INBOUND_​MESSAGE table. The behavior of externalSourceId parameter completely depends on the restrictNumberOfChars batch parameter, such as:

    • If the restrictNumberOfChars parameter is blank or set to zero, externalSourceId parameter is treated as an exact external source ID. The batch therefore creates a work unit only for that specific source and processes its eligible inbound messages.

    • If the restrictNumberOfChars parameter is greater than zero, system uses the specified number of leading characters in the externalSourceId parameter as the matching pattern for external source. The system first finds external source IDs that start with the specified prefix and creates a separate work unit for each matching group. It then processes all eligible inbound messages from every source ID in that group. Now, for instance, if the externalSourceId is 9111 and restrictNumberOfChars is 3, batch selects the 911 group and may go ahead and process the eligible inbound messages where the source ID is 9111, 9112, and the ones that begin with 911 series.

  • The inboundMessageType batch parameter filters the inbound message based on the specified inbound message type. Only inbound messages with a matching inboundMessageType are selected for processing. The inboundMessageType parameter references the C1_​INBOUND_​MSG_​TYPE_​CD column of the C1_​INBOUND_​MESSAGE table. When the inboundMessageType parameter is populated, the batch adds the filter of the inboundMessageType to both job-work and execute work unit selection. By applying this restriction at both the stages:

    • Work units are created only for external source groups which contain the respective inbound message type.

    • If the inboundMessageType parameter is blank, the system processes the inbound messages regardless of their inbound message type.

Note:

The externalSourceId and inboundMessageType are optional.

These parameters narrow the set of inbound messages selected during both job-work and execute-work-unit processing.

If neither parameter is specified, the batch continues to use its existing external-source partitioning behavior.

When both the parameters are specified, system applies both the conditions. An inbound message is eligible for processing only if it matches the external source criteria and the specified inbound message type.