|
|||
Processing of 837 EDI with NPI and Backend Selection Profile WorkflowWhen the profile workflow is underway, the XEServer Balance Counters function tracks the count of input claims and the count of generated acknowledgements and correlates these values to ensure that for each claim a corresponding acknowledegment has been generated and no data is stuck on the route. The Balance Counters module has numeric counters that represent certain data items (in this profile - claims and acknowledgements). The counters make up a logical condition (a completion expression) so once this condition is met, the system is considered balanced. For this profile, the condition yields TRUE when (roughly) each claim on input has a generated acknowledgement on output. For more information, open the Balance Counter configuration provided with this profile in EAM Counter Manager. When the profile receives data on the input, the Balance Counters module records the value of the received files. Then, as the profile execution moves forward, and the data items (claims and acknowledgements) pass different processing phases, the corresponding counters are updated. This way, by the end of the processing cycle, the Balance Counter is triggered, which means that none of the data items are stuck on the routes. Some of the profile's routes submit LDNS reports and acknowledgements to Edifecs Visualizer for the visualization of the workflow. To make the profile work with Visualizer Server, ensure that you have configured Visualizer Server (see Prerequisites section in the Profile Overview). XEServer Batcher accumulates positive and negative acknowledgements and sends out the accumulated batch once all the input claims have been processed. When you start the profile, the following events take place: Step 1. The 1 Claim Intake route splits an inbound claims batch into individual claims. Step 2: XEngine extracts the National Provider Identifier (NPI) and Subscriber ID for each good claim. Step 3. XEServer verifies the NPI validity against the HHS database, by using the https://npiregistry.cms.hhs.gov REST API. Step 4. Depending on the NPI verification results, the Groovy script sets a special marker property. The value of this property is either "Positive" or "Negative" and is used later to define the data flow on the 2 Create 277CAs route. Step 5. Claim data is directed to the 2 Create 277CAs route. Step 6. The route checks the AckKind property and forks the claim flow to generate positive and negative acknowledgements respectively. Step 7. To generate acknowledgements, XE Translator components use special map files located at ${XESProfileConfig}/configuration/Maps. Both positive and negative acknowledgements are pushed to Batcher. Additionally, the route directs positive acknowledgements to the 3 Delivery to Backend route. Step 8. Using the Crosswalk Lookup component and the LOB3 property (which holds the first three characters of the claim's Subscriber ID), the route determines the target back-end system to send the claim to. There are three available destinations: a web service emulation, a local backend emulation, and a directory on the file system that stores claims whose back-end destination could not be identified. Step 9. XEServer Batcher releases a batch of accumulated acknowledgements after all the individual claims from the original claim batch have been processed. Then, the route stages the acknowledgements and packs them into a single EDI document. The route stores the batch on the file system and updates the corresponding counter. This leads to the Balance Counter condition expression being met (the count of files before processing is the same as the count of files after processing) and activates the 5 BC completion route. Step 10. Once the Balance Counter completion expression yields TRUE, the route directs the batch of acknowledgements back to the sender. If you have connected to Visualizer Server, the route submits data to Visualizer Server for visualization. |
