MAO To CMS Encounter Reporting GA Scenarios - 02172012

Notes: 10/11/11 Created categories -- GA = Must have for GA Release; GA Revised = Must have for GA Release, Scenario has
been Revised Priorities -- GA = P1; GA Revised = P1; GA Lite = P2; Patch = P3 Complete Date Release Revised Priority Number Business Scenario
Regular Encounters
09/29/11 GA
P1
1a
Professional, Single Service Line
09/29/11 GA
P1
1b
Professional, Multiple Service Line Paid on Multiple 835's Institutional, One Inpatient, One Outpatient Encounter Generation Trigger Received, No Corresponding 835 Encounter Generation Trigger Received, No Inbound 837 received through eHub Internal Encounter Update Received for Claim Not Found in the Claims Repository Capitated/Delegated Encounters
09/29/11 GA
P1
1c
09/30/11 GA 10/10/11 GA Lite
P1 P2
1d 1e
10/10/11 Patch
P3
1g
2 09/30/11 GA P1 2a
Capitated/Delegated Encounters
3 10/10/11 Patch 10/10/11 Patch P3 P3 3a 3b
Deleted Encounters Deleted Professional Encounter - With 835 Deleted Professional Encounter Without 835 (Capitated/Delegated Encounters or Chart Reviews)
Corrected Adjusted Encounters
Added 12/6/11 Patch P3
P3
4a 4b
Corrected Adjusted Encounter Internal Encounter Update Received for Encounter Not Yet Acknowledged by CMS Internal Encounter Update Received for Encounter currently rejected and sitting on Exception List - not yet sent to CMS Internal Encounter Update Received for Encounter acknowledged by CMS but sitting on Exception List as a rejected encounter Internal Encounter Update Received for Encounter acknowledged by CMS as rejected and was sitting on Exception List but was resolved as Canceled Internal Encounter Update (Adjustment/Correction) Received for Claim Not Yet sent as an Encounter to CMS Chart Review Encounters
Patch
P3
4c
Patch
P3
4d
Patch
P3
4e
10/08/11 Patch
P3
4f
Added 11/22/11
GA
P2
5a
Professional Claims - Linked by CMS ICN
Added 11/22/11
GA
P2
5b
Institutional Claims - Linked by CMS-ICN
GA Lite
P2
5c
Not Linked by CMS ICN
Encounters Denied in Full or in Part
Patch
P3
7a
Encounter Denied in Full
10/08/11 Patch
P3 8
7b
Encounter Denied in Part CMS External Acknowledgements TA1 Not Yet Received for Outbound Interchange TA1 Received Indicating Rejection of the Interchange TA1 Received from CMS, Positive Acknowledgment 999 Acknowledgement Not Yet Received for Outbound Functional Group 999A Received from CMS, Positive Acknowledgement 999 Received Indicating Rejection of the Functional Group 999 Received Indicating Rejection of the Transaction 277CA Not Received from CMS Receive 277CA from CMS - Accepted Encounters Receive 277CA from CMS - Rejected Encounters
10/08/11 GA 10/08/11 GA Revised 10/08/11 GA 10/08/11 Patch
P1 P1 P1 P3
8b 8c 8d 8e
10/08/11 GA 10/08/11 GA Revised 10/08/11 GA Revised 10/08/11 Patch 10/10/11 GA 10/10/11 GA Revised
P1 P1 P1 P3 P1 P1
8f 8g1 8g2 8i 8j 8k
t have for GA Release, Scenario has been Revised; GA Lite = Should have for GA Release; Patch = Post GA Release
Description
This process flow outlines the receipt of an institutional 837 claim file containing two claims, and a professional 837 claim file containing one claim. There is nothing about the claims that require any special handling. The process follows the claims from receipt, through creation in TM and the Claim Repository, with an 835 adjudication/payment update, application of validation and business rules, and the generation of an outbound 837 encounter to CMS per CMS specifications. It also includes CMS-generated acknowledgement reconciliations. Happy Path This process flow outlines the receipt of a professional 837 claim file containing one claim with one service line, paid on a single 835 containing a single related claim This process flow outlines the receipt of a professional 837 claim file containing one claim. The claim contains three service lines. The first service line is paid on one 835, and the second and third service lines are paid on a subsequent 835. This process flow outlines the receipt of an institutional 837 claim file containing two claims - one inpatient and one outpatient. Both are paid on the same 835, however the 835 contains payments on multiple, unrelated claims. An ECHCF claim update is received to trigger generation of the encounter, but no payment information has been processed (835). The trigger process should fail with an appropriate error message. An ECHCF claim update is received to trigger generation of the encounter, but since the claim did not come through the eHub, there is no corresponding inbound 837. An update with an adjustment and a trigger to generate an encounter may be received for a claim that is not in the Claims Repository.
Capitated/delegated providers adjudicate and pay claims, and this information is removed from the claim by Humana before it is submitted to CMS as an encounter. This process flow outlines the receipt of a professional 837 claim file containing one capitated claim received from a trading partner. A "deleted claim" is a claim that was sent to Humana and then on to CMS as an encounter in error, and needs to be "deleted" out of the CMS system. Receipt of an 835 with encounter trigger notification indicating a deleted encounter. Receipt of an encounter trigger notification (without 835) indicating a deleted encounter.
A corrected or adjusted encounter is one that contains corrected or adjusted information that is different from what was submitted on the original claim. For example, the provider may have submitted the claim with a diagnosis of hypertension, but later realizes the diagnosis should have been diabetes. Since the incorrect diagnosis was reported to CMS on a previously submitted encounter, the "corrected" encounter needs to be submitted to CMS as a replacement. This process flow outlines the receipt of a professional 837 claim file containing one claim identified as a corrected adjusted claim. An update/trigger to generate an encounter may be received on an encounter that has already been sent to CMS but for which an acknowledgement has not yet been returned. An update with an adjustment and a trigger to generate an encounter may be received for a claim that has an encounter already in the process of being generated, but is currently sitting on an exception list because it failed internal validation. An update with an adjustment and a trigger to generate an encounter may be received for a claim that was sent to CMS, was rejected by CMS on the 277CA, and is sitting on the exception list.
An update with an adjustment and a trigger to generate an encounter may be received for an encounter that was sent to CMS, was rejected by CMS on the 277CA, but was resolved as "Canceled" on the exception list.
An update with an adjustment and a trigger to generate an encounter may be received for a claim but no encounter has been sent to CMS previously.
This process flow outlines the receipt of a professional 837 claim file containing one claim. (Chart reviews are only performed on professional encounters.) Insurance companies perform a certain number of random "chart review" audits, to ensure their contracted providers are submitting claims with complete and accurate diagnosis codes. Providers are required to submit a random sampling of patient chart notes to the plan, where clinicians review the chart information against the submitted claims (if there are submitted claims) to determine if accurate and complete diagnosis codes were reported on the claim. This audit can result in additional diagnosis codes identified that need to be reported to CMS. There are two types of chart review encounters - encounters that have been previously submitted to CMS and have a CMS-assigned claim number (ICN), and those that have not. CMS uses the ICN to "link" the chart review to the original encounter in the former scenario. In the latter scenario, the chart review submission is sent as a "first-time" encounter to CMS, with data elements which identify it as a chart review. Chart review encounters do not have service line detail. NOTE: There are also instances where diagnosis codes must be reported as "deleted" on chart review encounters. CMS specifications for reporting deleted diagnosis codes have not yet been finalized. Therefore, test scenarios and test data cannot be created for this scenario. Encounters previously submitted to CMS that have a CMS-assigned claim number (ICN) and which contain additional diagnosis codes identified during the chart review audit - but are not associated with an existing claim within the claim repository.
Encounters previously submitted to CMS that have a CMS-assigned claim number (ICN) and which contain additional diagnosis codes identified during the chart review audit - but are not associated with an existing claim within the claim repository. Encounters submitted for the first time to CMS that do not have a CMS-assigned claim number (ICN) but contain basic encounter data including diagnosis codes identified during the chart review process. These are encounters that are not linked to an inbound claim, and are referred to as "Superbill Chart Review Encounters" by Humana. These are also not associated with an existing claim within the claim repository - results in need to send a MINIMAL non-HIPAA compliant 837. This process flow outlines the receipt of one professional 837 claim file containing two claims. During the process of adjudication, one claim is denied in full, and the other claim is denied in part - i.e., of the three service lines on the claim, the first two are denied and the last is paid. In these instances, the denied claim and/or denied service lines must have the denial reason in the NTE segment on the outbound 837 encounter. Professional claim with three service lines, all service lines denied. NOTE: Humana has not determined how these will be handled yet, as denials are not reported at the claim level, only at the service line level, so this scenario cannot be created yet. Professional claim with three service lines, first two are denied, third is paid.
Description Data elements on the 835, how they map to the ECHCF, how they map to the CMS-ECHCF, and how they map to the outbound 837 encounter
File
Notes
835 Payment Data Elements
CMS Professional Encounter Required Fields

EDCompanion Guide 837P_11161
Attached current document 11/22/11.
CMS Institutional Encounter Required Fields

EDCompanionGuide 837I_111611.pdf
TA1 Acknowledgement File Fields

TA1 Fields
TA1 Interchange Error Codes

TA1 Interchange Error Codes
999 Acknowledgement File Fields

999 Fields
999E Syntax Error Code List

999E Errors
277CA Acknowledgement File Fields

277CA Fields
277CA Accept and Reject Code Sets

277CA Accept and Reject Code Sets
CMS Acknowledgement File Code Sets (All)

All Acknowledgement
CMS Encounter Guidelines

EDParticipantGuide _091311.pdf
Functional Requirements
Removed 11/22/11 most current functional requirements should be referenced on Wiki.
Scenario 1a
Step GA 1
Description "Happy Path" Professional, Single Service Line Simulate receipt of inbound professional 837 claim with one service line
Role
Tester
Simulate receipt of 835 and corresponding .properties file. 835 contains multiple Tester claim payments, one of which matches the EUO_PayerClaimControlNumber property. The claim payment contains a single service line payment which indicates that the service line was paid in full (SVC02 = SVC03). EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER". Outbound encounter generation automatically triggered. Claim is verified to be in System a finalized state, no outstanding encounters (i.e., not acknowledged). Outbound ECHCF encounter generated and stored in Claim Repository. Adjudication and payment information from the 835 is moved, using business rules, to Claim\ClaimCOBInfo at the claim level, and Claim\ServiceLineInfo\OtherPayerProcessedInfo at the service line level System
ECHCF mapped to outbound 837 encounter, passes compliance validation, System packaged within an outbound file, containing the single claim within a single 837 in a single functional in a single interchange and stored in TM Simulate TA1 inbound receipt process. (TA1 with accepted status and loaded to TM.) Tester
Simulate 999 inbound receipt process. (999 Received with accepted status and loaded to TM.)
Tester
Simulate 277CA inbound receipt process. (277CA Received with accepted status and loaded to TM.)
Tester
1b
GA 1
Professional, Multiple Service Line Paid on Multiple 835's Simulate receipt of inbound professional 837 claim with three service lines
Tester
Simulate receipt of 835 and corresponding .properties file. 835 contains multiple claim payments, one of which matches the EUO_PayerClaimControlNumber property. The claim payment contains information that the first service line was paid in full (SVC02 = SVC03). EUO_Classification property = "OUTBOUNDENCOUNTER-REPORT-TRIGGER". Claim is verified to be in a finalized state, no outstanding encounters (i.e., not acknowledged). It is NOT in a finalized state. Simulate receipt of 835 and corresponding .properties file. 835 contains multiple claim payments, one of which matches the EUO_PayerClaimControlNumber property. The claim payment contains information that the second and third service lines were paid in full (SVC02 = SVC03). EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER".
Tester
3 4
System Tester
Outbound encounter generation automatically triggered. Claim is verified to be in System a finalized state, no outstanding encounters (i.e. not acknowledged). Outbound ECHCF encounter generated and stored in Claim Repository. Adjudication and payment information from the 835 is moved, using business rules, to Claim\ClaimCOBInfo at the claim level, and Claim\ServiceLineInfo\OtherPayerProcessedInfo at the service line level System
ECHCF mapped to outbound 837 encounter, passes compliance validation, System packaged within an outbound file, containing the single claim within a single 837 in a single functional group in a single interchange and stored in TM
Simulate TA1 inbound receipt process. (TA1 with accepted status and loaded to TM.)
Tester
Tester
10
Tester
1c
GA 1
Institutional, One Inpatient, One Outpatient Simulate receipt of inbound institutional 837 containing two claims - one inpatient Tester and one outpatient
Simulate receipt of 835 and corresponding .properties file. Send the 835 file Tester through with the properties file for the first claim with matching EUO_PayerClaimControlNumber property. The claim payment contains information that the first claim is paid in full (SVC02 = SVC03). EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER". Simulate receipt of 835 and corresponding .properties file. Send the 835 file Tester through with the properties file for the second claim with matching EUO_PayerClaimControlNumber property. The claim payment contains information that the first claim is paid in full (SVC02 = SVC03). EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER". Outbound encounter generation automatically triggered. Claims are verified to be System in a finalized state, no outstanding encounters (i.e., not acknowledged).
Added Step 11/15 per bug 94945
Two outbound ECHCF encounter generated and stored in Claim Repository. Adjudication and payment information from the 835 is moved, using business rules, to Claim\ClaimCOBInfo at the claim level, and Claim\ServiceLineInfo\OtherPayerProcessedInfo at the service line level
System
Two ECHCF mapped to outbound 837 encounter, pass compliance validation, System packaged within an outbound file, containing the two claims within a single 837 in a single functional group in a single interchange and stored in TM
Simulate TA1 inbound receipt process. (TA1 with accepted status and loaded to TM.)
Tester
Tester
Tester
1d
GA 1
Encounter Generation Trigger Received, No Corresponding 835 Simulate receipt of inbound professional 837 claim with one service line
Tester
Simulate receipt of an ECHCF update with EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER"
Tester
Claim is verified to be in a finalized state, no outstanding encounters (i.e., not acknowledged).
System
1e
GA Lite Encounter Generation Trigger Received, No Inbound 837 received through eHub 1 2 3 Simulate receipt of an ECHCF update with EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER" The System searches for the corresponding ECHCF in the Claims Repository If the ECHCF cannot be located in the Claims Repository: a) Retry a configured number of times b) Wait a configured amount of time The System searches for the corresponding ECHCF in the Claims Repository Tester System System
System
1f
NA
Encounter Generation Trigger Received, Not All Claim Service Lines Finalized
1g
Patch Internal Encounter Update Received for Claim Not Found in the Claims Repository 1 Simulate receipt of an ECHCF update with EUO_Classification property = "CLAIMUPDATE" 2 The System searches for the corresponding ECHCF in the Claims Repository 3 If the ECHCF cannot be located in the Claims Repository: a) Retry a configured number of times b) Wait a configured amount of time The System searches for the corresponding ECHCF in the Claims Repository
Tester System System
System
1h-i
GA
Total claim charge amount must balance to sum of all service line charge amounts.
1.Simulate receipt of inbound professional 837 claim with multiple service lines in Tester which the total claim charge amount does not balance to the sum of all service line charge amounts reported in the Professional Service (SV1) segments for this claim. 2. Simulate receipt of 835 with corresponding payment information and corresponding .properties file.
1h-ii
GA
Continuation of 1h-i In the second step, the claim is corrected and revalidated.
Tester
Overall test status and reason for failure (if any):
1i
GA
System verifies that all service lines are associated with at least one diagnosis code i.e have diagnosis pointers. Simulate receipt of inbound professional 837 claim with multiple service lines and simulate receipt of 835 with corresponding payment information and corresponding .properties file.
Step
Expected Result
837 claim viewable in TM and ECHCF viewable in Claim Repository
Information merged with existing ECHCF in Claim Repository. ECHCF with adjudication and payment updates viewable in Claim Repository.
Claim is placed in the queue for the Generate Encounter Report route
ECHCF encounter visible in the Claims Repository as an attachment labeled "CMS EC-HCF"
Outbound 837 encounter visible in TM. Outbound file is written to the RIM outbound folder.
The TA1 is linked to the outbound interchange containing the 837 encounter in TM using the following keys:
Interchange Sender ID (ISA06) Interchange Receiver ID (ISA08) Interchange Control Number (TA101) The 999 is linked to the outbound functional group containing the 837 in TM using the following keys:
Functional Identifier Code (AK101) Application Receiver's Code (GS03) Application Sender's Code (GS02) Group Control Number (AK102) Implementation Convention Reference (AK103) The 277CA is linked to the outbound 837 in TM using the following keys:
277CA File Level Information Source Application Trace Number (Loop 2200B, TRN02) Information Receiver ETIN (Loop 2100B, NM109) Information Source ETIN (Loop 2100A, NM109) 277CA Claim Level Claim Transaction Batch Number (Loop 2200B, TRN02) Billing Provider Identifier (Loop 2100C, NM109) Patient Control Number (Loop 2200D, TRN02)
Information merged with existing ECHCF in Claim Repository. ECHCF with adjudication and payment updates viewable in Claim Repository.
3 4
Encounter trigger fails because claim is not finalized (not all service lines in a finalized status).
ECHCF encounter visible in the Claims Repository as an attachment labeled "CMS EC-HCF"
Interchange Sender ID (ISA06)
Interchange Receiver ID (ISA08) Interchange Control Number (TA101) The 999 is linked to the outbound functional group containing the 837 in TM using the following keys:
837 claims viewable in TM and ECHCF viewable in Claim Repository
First Claim - Information merged with existing ECHCF in Claim Repository. ECHCF with adjudication and payment updates viewable in Claim Repository.
Second Claim - Information merged with existing ECHCF in Claim Repository. ECHCF with adjudication and payment updates viewable in Claim Repository.
Claims are placed in the queue for the Generate Encounter Report route
Two ECHCF encounter visible in the Claims Repository as attachments labeled "CMS EC-HCF"
Interchange Sender ID (ISA06) Interchange Receiver ID (ISA08) Interchange Control Number (TA101) The 999 is linked to the outbound functional group containing the 837 in TM using the following keys:
Encounter trigger fails because claim is not finalized - claim adjudication/payment info is missing for ECHCF. An Event in TM is generated indicating "Trigger Encounter Cancelled" and an error in TM indicating the reason for cancellation. The claim ECHCF in this case is written to the CLAIM ERROR FOLDER.
1 2 3 ECHCF not found When retries are exhausted, the update goes to the Classification Router again.
If ECHCF is still not found, an error in processing occurs, the ECHCF update is routed to an Exception Worklist for error resolution EUO_Route = Process Claim Not Found, EUO_Error = Claim Not Found. The claim update-ECHCF in this case is written to the CLAIM ERROR FOLDER.
1 2 3 ECHCF not found When retries are exhausted, the update goes to the Classification Router again.
If ECHCF is still not found, an error in processing occurs, the ECHCF update is routed to an Exception Worklist for error resolution EUO_Route = Process Claim Not Found, EUO_Error = Claim Not Found. The claim ECHCF in this case is written to the CLAIM ERROR FOLDER
1. The system checks --Claim Level IsChartReviewInitiatedAdjustment false and (\Claim\ClaimAmounts\TotalClaimCharge equals the sum of \Claim\ServiceLineInfo\ServiceInfo\LineChargeAmount). In case, claim total charge does not balance with service lines: 1. Verify that an error is created on the TotalClaimCharge field with Normal Severity and message "Claim Charge Amount does not match sum of Service Line Charge amounts {sum LineChargeAmount}"-this shows under the error tab on TM UI. 2. The following fields with the corresponding values should be visible on both TM(general tab) and ECHCF: ECHCF --ExternalPartner ActivityState to "CPX" CurrentState = "Generation" Disposition = "In Progress" IsOpenException = "true"
After correction and revalidation the claim should show up on TM and event on the claim should state that the claim was corrected (this is there) also verify that the event says the user name who corrected it.
The system verifies that all service lines are associated with at least one diagnosis code i.e have diagnosis pointers. If (\Claim\ClaimIdentificationInfo\ClaimType = "ProfClaim") and ServiceLineInfo does not have any RelatedDiagnosisCodeInfo then system creates a error on RelatedDiagnosisCodeInfo with Normal Severity and setting message "Service Line diagnosis code is missing - must contain reference to at least one claim level diagnosis code" along with setting following fields as follows: EUO_Status = "Rejected" *Run time property* ECHCF --ExternalPartner ActivityState to "CPX" *Visible on both TM and ECHCF* CurrentState = "Generation" *Visible on both TM and ECHCF* Disposition = "In Progress" *Visible on both TM and ECHCF* IsOpenException = "true" *Visible on both TM and ECHCF*
Notes
Actual Result
Pass/Fail
Comments
Tester
See Embedded Documents "CMS Professional Encounter Required Fields" See Embedded Documents "835 Payment Data Elements"
See Embedded Documents "TA1 Acknowledgement File Fields"
See Embedded Documents "999 Acknowledgement File Fields"
See Embedded Documents "277CA Acknowledgement File Fields"
See Embedded Documents "CMS Professional Encounter Required Fields" See Embedded Documents "TA1 Acknowledgement File Fields"
See Embedded Documents "CMS Institional Encounter Required Fields" See Embedded Documents "835 Payment Data Elements"
See Embedded Documents "CMS Professional Encounter Required Fields" See Embedded Documents "TA1 Acknowledgement File Fields"
See Embedded Documents "CMS Professional Encounter Required Fields"
*This is a negative testing scenario so 837 should have CLM02 amount SV1 in case of professional files and SV2 in case of institutional files.
*This is a negative testing scenario so 837 should have diagnosis pointers missing from 2400 CO04 SV1 segment.
Date
Sample test Data Files
1h-i.zip
1h-i.zip
Scenario 2a
Step GA 1
Description
Role
Step
Capitated/Delegated Encounters Simulate receipt of inbound professional 837 claim with one Tester service line. Claim is from a capitated/delegated partner, and contains COB adjudication/payment information. Second ECHCF needs to be sent with at least one of these claim IDs present - OriginalClaimID, SubmittedClaimID, PreAdjClaimID, InternalClaimID, a Current State (regardless of value), and EUO_Classification set to OUTBOUNDENCOUNTER-REPORT-TRIGGER. Tester
Outbound encounter generation automatically triggered. System (Verification that claim is in finalized state is not performed for capitated claims - they are automatically set to finalized using business rule.) Business rules removes COB adjudication/payment System information from the ECHCF then generates outbound 837 encounter. Outbound ECHCF encounter generated and stored in Claim Repository. ECHCF mapped to outbound 837 encounter, passes compliance validation, packaged within an outbound file, containing the single claim within a single 837 in a single functional in a single interchange and stored in TM Simulate TA1 inbound receipt process. (TA1 with accepted status and loaded to TM.) System
Tester
Tester
Tester
Expected Result
Notes
See Embedded Documents "CMS Professional Encounter Required Fields"
Information merged with existing ECHCF in Claim Repository.
ECHCF encounter visible in the Claims Repository as an attachment labeled "CMS EC-HCF". COB adjudication/payment information is NOT present on the ECHCF. Outbound 837 encounter visible in TM. 2320 and 2430 COB loops do not contain any adjudication/payment information. Outbound file is written to the RIM outbound folder.
The TA1 is linked to the outbound interchange containing the 837 encounter in TM using the following keys: Interchange Sender ID (ISA06) Interchange Receiver ID (ISA08) Interchange Control Number (TA101) The 999 is linked to the outbound functional group containing the 837 in TM using the following keys: Functional Identifier Code (AK101) Application Receiver's Code (GS03) Application Sender's Code (GS02) Group Control Number (AK102) Implementation Convention Reference (AK103) The 277CA is linked to the outbound 837 in TM using the following keys:
277CA File Level Information Source Application Trace Number (Loop 2200B, TRN02) Information Receiver ETIN (Loop 2100B, NM109)
Information Source ETIN (Loop 2100A, NM109) 277CA Claim Level Claim Transaction Batch Number (Loop 2200B, TRN02) Billing Provider Identifier (Loop 2100C, NM109) Patient Control Number (Loop 2200D, TRN02)
Actual Result
Pass/Fail
Comments
Tester
Date
Scenario ID#
Step
Description
Role
3a
Deleted Professional Encounter - With 835
Regular encounter generation using steps from scenario 1a
Tester
Simulate the process of dropping 277CA with ICN(13 digits) linked to the Tester original encounter
Simulate the process of dropping second inbound 837-ECHCF with Claim/ExternalPartnerClaimStatus/RequestPartnerDeletion as "True" and property EUO_Classification set to OUTBOUND-ENCOUNTERREPORT-TRIGGER.
Tester
3b
Deleted Professional Encounter - Without an 835 (Capitated/Delegated Encounter or Chart Reviews) 1 2 Encounter generation using steps from scenario 2a Tester Simulate the process of dropping 277CA with ICN(13 digits) linked to the Tester original encounter Simulate the process of dropping second inbound 837-ECHCF with Claim/ExternalPartnerClaimStatus/RequestPartnerDeletion as "True" and Claim/Classifications/IsCapitated as "True" and property EUO_Classification set to OUTBOUND-ENCOUNTER-REPORT-TRIGGER. Overall test status and reason for failure (if any):
Tester
Step Expected Result
Regular encounter generated
The original claim gets updated to include CMS assigned ICN in the ClaimECHCF.
Claim-ECHCF viewable in Claim Repository with Claim/ExternalPartnerClaimStatus/RequestPartnerDeletion as "True".Adjustment encounter generated to delete the previously submitted to CMS.
1 2
Capitated encounter generated The original claim gets updated to include CMS assigned ICN in the ClaimECHCF. Claim-ECHCF viewable in Claim Repository with Claim/ExternalPartnerClaimStatus/RequestPartnerDeletion as "True" and Claim/Classifications/IsCapitated as "True". Adjustment encounter generated to delete the previously submitted delegated encounter to CMS.
Note Bug 97731,after revalidate I have problem described in bug 97025,because of doubling of nodes I have error that CAS 03 -Mandatory Element missing
Input Data Files
first_encounter.zip
277_TC3.dat
Deletion 837-ECHCF update.zip
ECHCF_trigger.zip
Scenario 4a Added 12/6/11
Step Corrected/Adjusted Encounter 1
Description
Repeat scenario 1a and link the encounter with 277CA. Simulate receipt of adjustment (837-ECHCF) with corresponding .properties file. Properties file contains EUO_Classification=CLAIM-UPDATE. Simulate receipt of adjusted payment (835-EDI) with corresponding .properties file. Properties file contains EUO_Classification=TRIGGER-ENCOUNTER-REPORT.
4b
Internal Encounter Update Received for Encounter Not Yet Acknowledged by Patch CMS
Repeat scenario 1a
Simulate the recepit of trigger to generate the encounter for the same claim-ECHCF needs to be sent with at least one of these claim IDs present OriginalClaimID, SubmittedClaimID, PreAdjClaimID, InternalClaimID, claim/claimstatus/activitystate,a Current State (regardless of value), and EUO_Classification set to OUTBOUND-ENCOUNTER-REPORT-TRIGGER.
4c
Internal Encounter Update Received for Encounter currently rejected and Patch sitting on Exception List - not yet sent to CMS Simulate a process wherein the encounter is genrated but fails internal validation. 1
Simulate the recepit of trigger to generate the encounter for the same claim-ECHCF needs to be sent with at least one of these claim IDs present OriginalClaimID, SubmittedClaimID, PreAdjClaimID, InternalClaimID, claim/claimstatus/activitystate, Current State (regardless of value), and EUO_Classification set to OUTBOUND-ENCOUNTER-REPORT-TRIGGER.
4d
Internal Encounter Update Received for Encounter acknowledged by CMS but Patch sitting on Exception List as a rejected encounter
Repeat scenario 1a
Simulate the drop and linkage of 277CA to the encounter 2
Simulate the recepit of trigger to generate the encounter for the same claim-ECHCF needs to be sent with at least one of these claim IDs present OriginalClaimID, SubmittedClaimID, PreAdjClaimID, InternalClaimID, claim/claimstatus/activitystate, a Current State (regardless of value), and EUO_Classification set to OUTBOUND-ENCOUNTER-REPORT-TRIGGER.
4e
Internal Encounter Update Received for Encounter acknowledged by CMS as Patch rejected and was sitting on Exception List but was resolved as Canceled 1 2 3 Repeat scenario 1a Simulate the drop and linkage of 277CA to the encounter with error. Encounter on the exception list is cancelled as a part of resolution action of the correction UI. Simulate the recepit of trigger to generate the encounter for the same claim-837-ECHCF needs to be sent with at least one of these claim IDs present OriginalClaimID, SubmittedClaimID, PreAdjClaimID, InternalClaimID, claim/claimstatus/activitystate, Current State (regardless of value), and EUO_Classification set to OUTBOUND-ENCOUNTER-REPORT-TRIGGER.
Role
Step
Tester
Tester
Tester
Tester
Tester
Tester
Tester
Tester
Tester
Tester
Expected Result
See scenario 1a with the base claim updated with CMS ICN on 277CA. Information merged with existing base version of the ECHCF in Claim Repository. Note: Claim\Classification\ProviderInitiatedAdjustment=True or Claim\Classification\PlanInitiatedAdjustment=True Outbound encounter is generated properly (service lines are finalized with updated payment information that came on 835 outbound trigger file. Key fields on the outbound 837 encounter are listed below). Business Rule: EUO_FrequencyType_7 --- Key fields: 2300, CLM05-3=7 2300, REF02=CMS-assigned ICN (from initial encounter submitted to CMS)
An update/trigger to generate an encounter may be received on an encounter that has already been sent to CMS but for which an acknowledgement has not yet been returned.
Encounter generated but there is no corresponding TA1, 999 or 277CA.
The system verifies that the inbound claim has claim/claimstatus/activitystate = application processing(AP) and whether the corresponding Encounter has been sent to CMS, and acknowledged by CMS--i.e. TA1, 999 or 277CA exist for the corresponding encounter. If the encounter hasn't been acknowledgement by CMS (\Claim\ExternalPartnerClaimStatus\CurrentState="Delivery" or "Generation") then system will not create a new encounter and claim ECHCF is written to the CLAIM ERROR FOLDER and TM shows activitystate as APX. The system also creates an error on Claim\ExternalPartnerClaimStatus with Information Severity and message="Encounter Trigger Cancelled - encounter already in progress to CMS", along with setting the following fields as follows: EUO_IsEncounterNotReady to true, LifecycleUpdateInfo\BusinessItemCID\Name="InternalClaimD", LifecycleUpdateInfo\BusinessItemCID\Value=EUO_TargetTrackingID, set LifecycleUpdateInfo\EventInfo\EventType = "AP", LifecycleUpdateInfo\EventInfo\EventTopic = "TriggerEncounterCancel", LifecycleUpdateInfo\EventInfo\Message = "Encounter Trigger Cancelled" , LifecycleUpdateInfo\EventInfo\Severity = "NORMAL", LifecycleUpdateInfo\EventInfo\Situation\Date = current date, LifecycleUpdateInfo\EventInfo\Situation\Time = current time, LifecycleUpdateInfo\EventInfo\SourceComponent\URL = "CLM", LifecycleUpdateInfo\EventInfo\SourceComponent\SubComponent = "EUO_Process_Encounter_Trigger" Refer the following business rules for details : EUO_EncounterTrigger_CancelAlreadyInProgress
An update with an adjustment and a trigger to generate an encounter may be received for a claim that has an encounter already in the process of being generated, but is currently sitting on an exception list because it failed internal validation. Encounter generated but is sent to exception work list due to internal validation failure.
The system verifies that the inbound claim/claimstatus/activitystate = Application Processing(AP)and Encounter already exists for the corresponding claim and is not rejected or waiting for exception resolution. If a rejected encounter already exists for the related claim and is present on the exception work list, the system will not generate a new encounter and would rather show the following error-Claim\ExternalPartnerClaimStatus with Information Severity and message="Encounter Trigger Cancelled - encounter already in progress to CMS" Refer the following business rules for details : EUO_EncounterTrigger_CancelAlreadyInProgress
An update with an adjustment and a trigger to generate an encounter may be received for a claim that was sent to CMS, was rejected by CMS on the 277CA, and is sitting on the exception list.
Encounter generated and sent to CMS
Error is reported on 277CA and the encounter is placed on the exception worklist for error resolution.
The system verifies that in the inbound claim/claimstatus/activitystate = Application Processing(AP)and Encounter already exists for the corresponding claim and is not rejected or waiting for exception resolution. If a rejected encounter already exists for the related claim and is present on the exception work list, the system will not generate a new encounter and claim ECHCF is written to the CLAIM ERROR FOLDER and TM shows activitystate as APX. The system also creates an error on Claim\ExternalPartnerClaimStatus with Information Severity and message=, "Encounter Trigger Cancelled - encounter rejected by Partner but currently exists on exception worklist", The system also sets the following fields: EUO_IsEncounterNotReady to true, LifecycleUpdateInfo\BusinessItemCID\Name="InternalClaimD", LifecycleUpdateInfo\BusinessItemCID\Value=EUO_TargetTrackingID, LifecycleUpdateInfo\EventInfo\EventType = "AP", LifecycleUpdateInfo\EventInfo\EventTopic = "TriggerEncounterCancel", LifecycleUpdateInfo\EventInfo\Message = "Encounter Trigger Cancelled" , LifecycleUpdateInfo\EventInfo\Severity = "NORMAL", LifecycleUpdateInfo\EventInfo\Situation\Date = current date, LifecycleUpdateInfo\EventInfo\Situation\Time = current time, LifecycleUpdateInfo\EventInfo\SourceComponent\URL = "CLM", LifecycleUpdateInfo\EventInfo\SourceComponent\SubComponent = "EUO_Process_Encounter_Trigger"
Encounter generated and sent to CMS Error is reported on 277CA and the encounter is placed on the exception worklist for error resolution. The system stops processing of the Encounter and an event is created that reporting Encounter must be resubmitted. The system generates a new encounter now.
Note
Input Data Files
Scenario is working only if last filecontains expected values for rule : EUO_EncounterTrigger_CancelAlreadyInProgres s. Wait response.
first_encounter.zip
ECHCF.zip
Please review my input files.Have same problem.If last file contain expected values for firing rule,scenario works,in rest cases no.I think this is not correct.
837.rar
Update.zip
835_as_rejection.rar
EncounterNotReady.zip
Scenario is working only if last file contains expected values for firing rule : EUO_EncounterTrigger_CancelOpenExcepti on.Please review my files and question.
first_encounter.zip
277_T C 3.dat
ECHCF.zip
N/A
Batch result
TRACE-20120112-123941-0000841.dat
batch_result_4b.zip
EncounterNotReady.zip
N/A
Comments/Questions
Not sure that result is the expected one.I receive Encounter Trigger Cancelled - encounter already in progress to CMS only in case if second encounter contains expected for rule values .[Valentina]
Bug # 97865 has been logged in to check if changes are required to the rule EUO_EncounterTrigger_CancelAlreadyInProgress and also, if any mapping changes are required to ensure that claim/claimstatus/activitystate gets populated on claim-ECHCF.[Gary]
The Claim\ExternalPartnerClaimStatus\CurrentState="In Progress" and \Claim\ExternalPartnerClaimStatus\IsOpenException = true should be assigned by the system to a claim.[Gary]
After I processed: 1.837 P; 2.835 ; 3.277 ; 4. ECHCF .After this if last ECHCF contains value for firing the rule(ExternalPartnerClaimStatus/CurrentState=Rejected and IsOpenException=true).If values for CurrentState and IsOpenException come from already loaded file, EUO_Status will be rejected for this file, and first encounter will not be loaded in UI.The value of node IsOpenException = false is set by rule, condition for execution is Claim. Is this correct? The Claim\ExternalPartnerClaimStatus\CurrentState="In Progress" and \Claim\ExternalPartnerClaimStatus\IsOpenException = true should be assigned by the system to a claim.[Gary]
Not provided
Scenario 5a
Step GA 1
Description Chart Review With Linked CMS-ICN - Professional Claims Complete 1A scenario using professional files already provided.
Role
Tester
Simulate receipt of an ECHCF chart review update along with Tester properties file.
2a
The ECHCF chart review update should have the following Tester fields as contained in the embedded document.
2b
The corresponding properties file should contain EUO_Classification_TRIGGER-ENCOUNTER-REPORT.
Tester
5b
GA 1
Chart Review With Linked CMS-ICN - Institutional Claims Complete 1A scenario using institutional files already provided (via email from Diane dated 11/21 and 11/22). Tester
Simulate receipt of an ECHCF chart review update along with Tester properties file.
2a
The ECHCF chart review update should have the following Tester fields as contained in the embedded document.
2b
The corresponding properties file should contain EUO_Classification_TRIGGER-ENCOUNTER-REPORT.
Tester
5c
GA
Not Linked by CMS ICN-SUPERBILL
Step 1: Drop ECHCF, as a direct submitted claim, with Tester Claim/Classifications/IsChartReviewInitiatedAdjustment="tr ue" but NO Claim/ClaimIdentificationInfo/CMSClaimControlNumber Step 2: Second ECHCF needs to be sent with at least one of these claim IDs present - OriginalClaimID, SubmittedClaimID, PreAdjClaimID, InternalClaimID, a Current State and EUO_Classification set to OUTBOUNDENCOUNTER-REPORT-TRIGGER. Overall test status and reason for failure (if any):
5d
GA
Verify that the Principal Diagnosis exists Step 1: Drop ECHCF, as a direct submitted claim, with Tester Claim/Classifications/IsChartReviewInitiatedAdjustment="tr ue" but NO Claim/ClaimIdentificationInfo/CMSClaimControlNumber Step 2: Second ECHCF needs to be sent with at least one of these claim IDs present - OriginalClaimID, SubmittedClaimID, PreAdjClaimID, InternalClaimID, a Current State (regardless of value), and EUO_Classification set to OUTBOUND-ENCOUNTER-REPORT-TRIGGER.
Step
Expected Result Batch result
Input file
Updated ECHCF in Claim Repository. After the 277CA update, the claim in the Claim Respository must contain the CMS-assigned ICN number. Encounter generated with minimum data elements as outlined in CMS Participant Guide, Table 2B1, on Embedded Documents tab. Also refer to Business Rule "EUO_ChartReview_FrequencyType_7" for expected results.
Chart_ReviewP_batch.zip
2a
ECHCF Chart Reviews V1.xml

2b
ECHCF Chart Reviews V1.xml.properties
Updated ECHCF in Claim Repository. After the 277CA update, the claim in the Claim Respository must contain the CMS-assigned ICN number. Encounter generated with minimum data elements as outlined in CMS Participant Guide, Table 2B1, on Embedded Documents tab. Also refer to Business Rule "EUO_ChartReview_FrequencyType_7" for expected results.
ChartReviewI_batch.zip
2a
ECHCF Chart Reviews V1.xml
2b
1 The system verifies the presence of Claim/Classifications/IsChartReviewInitiatedAdj ustment="true" and absence of Claim/ClaimIdentificationInfo/CMSClaimControl Number to ascertain that it is a case of SUPER BILL(Chart Review with no linked ICN) and generates the SUPERBILL encounter.
For_Super_Bill.xml
If * This negative scenario has to be Claim\ClaimDetails\HealthInformation\Principal tested by removing principal Diagnosis\DiagnosisCode does not exist diagnosis code from the input file. or PrincipalDiagnosis does not exist or HealthInformation does not exist or Claim Details does not exist then the system should create an error on PrincipalDiagnosis with Normal Severity setting message as "Principal Diagnosis is missing", along with setting following fields as follows: EUO_Status = "Rejected" ECHCF ExternalPartner ActivityState to "CPX", CurrentState = "Generation", Disposition = "In Progress", IsOpenException = "true"
Comments/Questions
Scenario 7a
Step Patch 1
Description Encounter Denied in Full Simulate receipt of inbound professional 837 claim with three service lines
Simulate receipt of 835 and corresponding .properties file. 835 contains multiple claim payments, one of which matches the EUO_PayerClaimControlNumber property. The claim payment contains information that the first,second and third service lines were denied--i.e. there were no payments for these service lines : 835-loop 2100--CLP04=0 and CAS01=PR, CAS03=full charge amount. 835-loop 2110-- SVC03=0 and CAS01=PR, CAS03= full charge amount Total balancing equation: Total charge amount-(Total payment amount+ adjusted amount)= 0 EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER".
7b
Patch 1
Encounter Denied in Part Simulate receipt of inbound professional 837 claim with three service lines
Simulate receipt of 835 and corresponding .properties file. 835 contains multiple claim payments, one of which matches the EUO_PayerClaimControlNumber property. The claim payment contains information that the first and second service lines were paid in full (SVC02 = SVC03). The third service line is denied--835-loop 2110-- SVC03=0 and CAS01=PR, CAS03= full charge amount . EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER".
Role
Step
Tester
Tester/System
Tester
Tester/System
Expected Result
Outbound 837 encounter is generated and is visible in TM.
Outbound encounter generation automatically triggered. Claim is verified to be in a finalized state, no outstanding encounters (i.e. not acknowledged).Outbound 837 is generate and is encounter visible in TM.
Notes
Input Data Files
Batch result
837.zip
BatchResult.zip
QA can use the files being used for scenario 1a with minor variation as detailed in the steps of scenario.
835.zip
837.zip
BatchedResults.zip
835.zip
Comments/Questions
Please review input files and confirm that batch is the expected one.
Please review input files and batch result.
8. Process CMS External File Acknowledgements Scenario ID# Step 8a 1 2 3 8b GA 1 2
Description
Receive TA1 from CMS Monitor for receipt of TA1 from CMS Receive TA1 from CMS Add corresponding event to TM, visible in TM TA1 Not Yet Received for Outbound Interchange Simulate TA1 not received from CMS after specified time period has elapsed (timer). System creates exception and event for transmission ID indicating acknowledgement missing. System will use EUO_AckReconID as correlation ID for creation of event and exception in TM. System provides user ability to perform actions
4 8c
System provides user ability to perform resolution actions
GA TA1 Received Indicating Rejection of the Interchange Revised 1 Simulate TA1 inbound receipt process. (TA1 with rejected status and loaded to TM.)
Patch
2 3
Receive TA1 "negative acknowledgement" from CMS The System uses business rules to analyze the information on the acknowledgements and updates the status of the CMS encounter in TM (i.e., Status, Event, Errors). Specific Rule: EUO_NegativeAckException.
Patch
System provides user ability to perform actions
Patch 8d
5 GA 1
System provides user ability to perform resolution actions TA1 Received from CMS, Positive Acknowledgment Simulate TA1 inbound receipt process. (TA1 with accepted status and loaded to TM.)
Receive TA1 "positive acknowledgement" from CMS
The System uses business rules to analyze the information on the acknowledgement and loads the item into TM. 999 Acknowledgement Not Yet Received for Outbound Functional Group Simulate 999 not received from CMS after specified time period has elapsed (timer). System creates exception and event for transmission ID indicating acknowledgement missing. System will use EUO_AckReconID as correlation ID for creation of event and exception in TM. System provides user ability to perform actions
8e
Patch 1 2
4 8f GA 1
System provides user ability to perform resolution actions 999A Received from CMS, Positive Acknowledgement Simulate 999 inbound receipt process. (999 Received with accepted status and loaded to TM.)
2 3 4
Receive 999 "positive acknowledgement" from CMS (IK501 and AK901 = "A") The System uses business rules to analyze the information on the acknowledgement and loads the item into TM. System updates Lifecycle info on the ECHCF
8g1
GA 999 Received Indicating Rejection of the Functional Group Revised 1 Simulate 999R inbound receipt process. (999R Received with rejected status and loaded to TM.) Receive 999 "negative acknowledgement" from CMS (IK501 and AK901 = "R")
System will use EUO_AckReconID as correlation ID for creation of event and exception in TM.
Patch
System uses business rules to analyze the information on the acknowledgements and creates exception and event for transmission ID indicating acknowledgement missing (i.e., Status, Event, Errors). Specific Rule: EUO_Negative999GroupControlFailure
Patch
System updates Lifecycle info on the ECHCF
Patch
Patch 8g2
GA 999 Received Indicating Rejection of the Transaction Revised 1 Simulate 999R inbound receipt process. (999R Received with rejected status and loaded to TM.) Receive 999 "negative acknowledgement" from CMS (IK501 and AK901 = "R")
2 Patch 3
System will use EUO_AckReconID as correlation ID for creation of event and exception in TM. System uses business rules to analyze the information on the acknowledgements and creates exception and event for transmission ID indicating acknowledgement missing (i.e., Status, Event, Errors). Specific Rule: EUO_Negative999TransactionControlFailure
Patch
System updates Lifecycle info on the ECHCF
Patch
Patch 8h 8i
6 NA Patch
System provides user ability to perform resolution actions Receive 999E from CMS - Functional Group Accepted, With Errors 277CA Acknowledgement Not Yet Received for Outbound 837 Transaction 1 Simulate 277CA not received from CMS after specified time period has elapsed (timer)
2 System creates exception and event for transmission ID indicating acknowledgement missing. System will use EUO_AckReconID as correlation ID for creation of event and exception in TM. 8j GA 1 Receive 277CA from CMS - Accepted Encounters Simulate 277CA inbound receipt process.
2 3
277CA Received and loaded to TM. The System splits the 277CA into individual claim acknowledgements
The 277CA positive acknowledgements (STC03 = "WQ") are converted into claim update to the ECHCF
The System identifies the corresponding encounter in the Claims Repository, and merges the information from the update. System updates Lifecycle info on the ECHCF.
8k
GA Receive 277CA from CMS - Rejected Encounters Revised 1 Simulate 277CA inbound receipt process.
2 3
277CA Received and loaded to TM The System splits the 277CA into individual claim acknowledgements and loaded TM
Patch
The 277CA negative acknowledgements (STC03 = "U", STC01 = reject code) are converted into claim update to the ECHCF
Patch
The System identifies the corresponding encounter in the Claims Repository, and merges the information from the update. System updates Lifecycle info on the ECHCF.
Patch
Patch
Role
Step
Expected Result
Event visible in TM
Tester/System
1 2 Exception created in TM - "TA1 not yet received for outbound interchange" The following actions are available to the user in TM: Add a Note , Attach Supported Documentation, Check Out, Check In, Cancel Check Out Resolution Actions available include: Resend, Cancel
System
System
Tester
The TA1 is linked to the outbound interchange containing the 837 encounter in TM using the following keys: Interchange Sender ID (ISA06) Interchange Receiver ID (ISA08) Interchange Control Number (TA101) Kill Timer associated with passed EUO_AckReconID Exception created in TM - "TA1 Received Indicating Rejection of Interchange" Verify an R is in the TA104 data element. Verify an error code appears in TA105 from the list in the embedded document "TA1 Interchange Error Codes". The following actions are available to the user in TM: Add a Note , Attach Supported Documentation, Check Out, Check In, Cancel Check Out Resolution Actions available include: Resend, Cancel
System Tester
2 3
System
System
Tester
The TA1 is linked to the outbound interchange containing the 837 encounter in TM using the following keys: Interchange Sender ID (ISA06) Interchange Receiver ID (ISA08) Interchange Control Number (TA101) Kill Timer associated with passed EUO_AckReconID
System
System
Item visible in TM.
Tester System
1 2 Exception created in TM - "999 Acknowledgement not yet received for outbound functional group" The following actions are available to the user in TM: Add a Note , Attach Supported Documentation, Check Out, Check In, Cancel Check Out Resolution Actions available include: Resend, Cancel
System
System
Tester
The 999 is linked to the outbound functional group containing the 837 in TM using the following keys: Functional Identifier Code (AK101) Application Receiver's Code (GS03) Application Sender's Code (GS02) Group Control Number (AK102) Implementation Convention Reference (AK103) Kill Timer associated with passed EUO_AckReconID Item visible in TM. Event indicates item positive acknowledgement was received. Current Activity State on TM changes to "CP" (Channel Processing) Refer to EUO_Accepted999Transaction for list of fields that are updated and their values.
System System System
2 3 4
Tester
The 999R is linked to the outbound functional group containing the 837 in TM using the following keys: Functional Identifier Code (AK101) Application Receiver's Code (GS03) Application Sender's Code (GS02) Group Control Number (AK102) Implementation Convention Reference (AK103) Kill Timer associated with passed EUO_AckReconID
System
System
The entire functional group is reported as rejected, and the reason code indicates a control type (not data compliance) failure, and there are no transaction level compliance errors: The system sets the outbound functional group as rejected The system creates an event indicating functional group failure The system places the item on the exception worklist as a functional group failure with message "999 received indicating rejection of the functional group" Current Activity State on TM changes to "CP" (Channel Processing) Refer to EUO_Negative999GroupControlFailure for list of fields that are updated and their values. The following actions are available to the user in TM: Add a Note , Attach Supported Documentation, Check Out, Check In, Cancel Check Out Resolution Actions available include: Resend, Cancel
System
System
System
Tester
The 999R is linked to the outbound functional group containing the 837 in TM using the following keys: Functional Identifier Code (AK101) Application Receiver's Code (GS03) Application Sender's Code (GS02) Group Control Number (AK102) Implementation Convention Reference (AK103) Kill Timer associated with passed EUO_AckReconID The entire functional group is not rejected for a functional group control failure for each transaction that is rejected for a control failure: The system sets the outbound transaction as rejected The system creates an event indicating transaction failure and places it on the exception worklist as a transaction failure with message "999 Acknowledgement reported compliance error associated with this transaction"
System System
2 3
System
Current Activity State on TM changes to "CP" (Channel Processing) Refer to EUO_Negative999TransactionControlFailure for list of fields that are updated and their values.
System
System
The following actions are available to the user in TM: Add a Note , Attach Supported Documentation, Check Out, Check In, Cancel Check Out Resolution Actions available include: Resend, Cancel
Tester
System
1 System creates exception and event for transmission ID indicating acknowledgement missing. System will use EUO_AckReconID as correlation ID for creation of event and exception in TM. 2 Exception created in TM - "277CA Acknowledgement not yet received for outbound 837 transaction"
Tester
The 277CA is linked to the outbound 837 in TM using the following keys: 277CA File Level Information Source Application Trace Number (Loop 2200B, TRN02) Information Receiver ETIN (Loop 2100B, NM109) Information Source ETIN (Loop 2100A, NM109) 277CA loaded to TM, visible in TM 277CA individual acknowledgement visible in TM. 277CA attached to claim at claim level using the following keys: 277CA Claim Level Claim Transaction Batch Number (Loop 2200B, TRN02) Billing Provider Identifier (Loop 2100C, NM109) Patient Control Number (Loop 2200D, TRN02)
System System
2 3
System
On the positive acknowledgement, code STC01-1 (aka 507 codes) will be populated with the healthcare claim status category code and STC01-2 (aka 508 codes) will be populated with the healthcare claim status code. Every ExternalPartnerClaimStatus\ClaimStatus with change attribute = NEW contains StatusCode\StatusCategoryCode(s) where all are in list "A1" If an encounter is accepted, the 277CA will provide the ICN assigned to that encounter. The ICN segment for the accepted encounter will be located in REF segment, REF01=IK and REF02=ICN. The ICN is a unique 13-digit number. Location of CMS ICN on CMSECHCF = Claims\ClaimIdentificationInfo\PayerClaimControlNumber.
System
Current version of the encounter viewable in TM. Current Activity State on TM changes to "EP" (External Processing). Claim status updated and CMS-assigned claim identifier added. See rule EUO_ClaimAck_SetStatus_Accepted for fields on the CMS-ECHCF that are updated and with what values.
Tester
The 277CA is linked to the outbound 837 in TM using the following keys: 277CA File Level Information Source Application Trace Number (Loop 2200B, TRN02) Information Receiver ETIN (Loop 2100B, NM109) Information Source ETIN (Loop 2100A, NM109) 277CA loaded to TM, visible in TM 277CA individual acknowledgement visible in TM. 277CA attached to claim at claim level using the following keys: 277CA Claim Level Claim Transaction Batch Number (Loop 2200B, TRN02) Billing Provider Identifier (Loop 2100C, NM109) Patient Control Number (Loop 2200D, TRN02)
System System
2 3
System
On the negative acknowledgement, code STC01-1 (aka 507 codes) will be populated with the healthcare claim status category code and STC01-2 (aka 508 codes) will be populated with the healthcare claim status code. Every ExternalPartnerClaimStatus\ClaimStatus with change attribute = NEW contains StatusCode\StatusCategoryCode(s) where all are in list "A3,A6,A7,A8". Note: For rejected encounters, an ICN is not returned from CMS. Current version of the encounter viewable in TM. Activity State on TM changes to "CP" (Channel Processing) See rule EUO_ClaimAck_SetStatus_Rejected for fields on the CMS-ECHCF that are updated and with what values.
System
System
System
The following actions are available to the user in TM: Add a Note, Attach Supporting Documentation, View Related Inbound Encounter, Cancel Check Out, Check In, Edit Encounter Content/Errors Resolution Actions available include: Revalidate Encounter, Override Encounter Errors, Cancel Encounter
Notes
Actual Result
See Embedded Documents "TA1 Interchange Error Codes"
8i_e.rar
Same as 8e ,scenario works
oop 2200B, TRN02)
See Embedded Documents "277CA Accept and Reject Code Sets"
oop 2200B, TRN02)
See Embedded Documents "277CA Accept and Reject Code Sets"
Pass/Fail
Comments
Tester
Scenario works,attached screenshot
Screenshot.rar
Date
Scenario ID#
Description /Expected Result
Role
Step1--Generate 837 encounter batch file-(using multiple inbound 837 and 835s) Step 2--Simulate the process of linking the following acknowledgements in two cases: 1. 999R 2. 999A and 277CA Step3: Test the following newly integarted features of the CLM functionality -9a through 9E. * QAs can use the Humana's testfiles placed on QA server by Kumar.
9(a)
New Features indicates that 999 and 277CA errors should be viewable on the data view of the outbound 837 transaction or individual claim errors should contain the descriptions associated with the 999/277CA error codes. New Features indicates that 999 and 277CA rejected encounters should have an activitystate of EPX. New Features indicates that user can manually reject an outbound claim even if the transaction is accepted (requires administrator)
9(b)
9(c)
9(d)
New Features indicates that manual rejection of an encounter should cause encounter to have an activity state of EPX New Feature indicates that Cancelling a Correction should cause the Activity State to be set to CP
9(e)
Actual Result
Notes
Pass/Fail
Comments
Tester
Date

MAO To CMS Encounter Reporting GA Scenarios - 02172012

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MAO To CMS Encounter Reporting GA Scenarios - 02172012

Hochgeladen von

Copyright:

Verfügbare Formate

Notes: 10/11/11 Created categories -- GA = Must have for GA Release; GA Revised = Must have for GA Release, Scenario has

Professional, Single Service Line

09/30/11 GA 10/10/11 GA Lite

3 10/10/11 Patch 10/10/11 Patch P3 P3 3a 3b

Corrected Adjusted Encounters

Added 12/6/11 Patch P3

Professional Claims - Linked by CMS ICN

Institutional Claims - Linked by CMS-ICN

Not Linked by CMS ICN

Encounters Denied in Full or in Part

Encounter Denied in Full

10/08/11 GA 10/08/11 GA Revised 10/08/11 GA 10/08/11 Patch

835 Payment Data Elements

CMS Professional Encounter Required Fields

Attached current document 11/22/11.

CMS Institutional Encounter Required Fields

Attached current document 11/22/11.

TA1 Acknowledgement File Fields

TA1 Interchange Error Codes

999 Acknowledgement File Fields

999E Syntax Error Code List

277CA Acknowledgement File Fields

277CA Accept and Reject Code Sets

CMS Acknowledgement File Code Sets (All)

CMS Encounter Guidelines

Attached current document 11/22/11.

Removed 11/22/11 most current functional requirements should be referenced on Wiki.

Added Step 11/15 per bug 94945

Simulate receipt of an ECHCF update with EUO_Classification property = "OUTBOUND-ENCOUNTER-REPORT-TRIGGER"

Claim is verified to be in a finalized state, no outstanding encounters (i.e., not acknowledged).

Tester System System

Overall test status and reason for failure (if any):

Overall test status and reason for failure (if any):

837 claim viewable in TM and ECHCF viewable in Claim Repository

837 claim viewable in TM and ECHCF viewable in Claim Repository

Interchange Sender ID (ISA06)

837 claims viewable in TM and ECHCF viewable in Claim Repository

837 claim viewable in TM and ECHCF viewable in Claim Repository

See Embedded Documents "TA1 Acknowledgement File Fields"

See Embedded Documents "999 Acknowledgement File Fields"

See Embedded Documents "277CA Acknowledgement File Fields"

See Embedded Documents "999 Acknowledgement File Fields"

See Embedded Documents "277CA Acknowledgement File Fields"

See Embedded Documents "999 Acknowledgement File Fields"

See Embedded Documents "277CA Acknowledgement File Fields"

See Embedded Documents "CMS Professional Encounter Required Fields"

Sample test Data Files

837 claim viewable in TM and ECHCF viewable in Claim Repository

See Embedded Documents "CMS Professional Encounter Required Fields"

Information merged with existing ECHCF in Claim Repository.

See Embedded Documents "TA1 Acknowledgement File Fields"

See Embedded Documents "999 Acknowledgement File Fields"

See Embedded Documents "277CA Acknowledgement File Fields"

Sample test Data Files

Deleted Professional Encounter - With 835

Regular encounter generation using steps from scenario 1a

Overall test status and reason for failure (if any):

Step Expected Result

Regular encounter generated

Input Data Files

Deletion 837-ECHCF update.zip

Scenario 4a Added 12/6/11

Step Corrected/Adjusted Encounter 1