OMHSAS CCRI Encounter Data Reporting Overview
The Consolidated Community Reporting Initiative (CCRI) aims to establish a statewide data infrastructure for reporting consumer-level service utilization and outcome information in mental health services. The objective is to ensure timely and accurate submission of encounter data to support this initiative. The process involves sending the 837 Encounter file for validation through Business Exchange Services (BES) and PROMISe. Full File Rejects may occur due to HIPAA compliance issues or security validations. Addressing these challenges is crucial for meeting submission requirements.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Office of Mental Health and Substance Abuse Services (OMHSAS) Consolidated Community Reporting Initiative (CCRI) Encounters Overview April 29, 2022 04/02/22 1
Overview The objective of the Consolidated Community Reporting Initiative (CCRI) is to build the statewide data infrastructure necessary to report consumer-level service utilization and outcome information on persons receiving County base-funded mental health services. A key part of this reporting effort is the submission of Encounter Data. 04/02/22 2
Encounter Data Requirements To accomplish this objective, it is imperative that OMHSAS receive timely and accurate encounter data. The current requirement is 90% of encounters successfully submitted into CCRI within 90 calendar days of the County/Joinder accepting payment responsibility and 100% of submissions entered within 180 calendar days of the encounter. Submissions are recorded monthly; therefore, monthly submissions are preferred. However, submissions should be made at least quarterly to comply with these requirements. Currently, we are not reaching this goal for many of the counties/joinders, so we are hosting this overview session today to provide guidance as to how you can obtain information and assistance. 04/02/22 3
Encounter Data Process 837 Encounter file is sent from the county/joinder to Business Exchange Services (BES) through SeGov. BES is a HIPAA Translator. Once the information reaches BES, it is reviewed for HIPAA compliance If the file is HIPAA Compliant, it is transferred to PROMISe where it is validated for accuracy. If the file is not HIPAA Compliant, it is sent back as a full file reject and none of the encounters are processed. Or does not pass security validations (e.g. submitter id). If the file is HIPAA Complaint, but some of the encounters set HIPAA edits, those encounters will reject at the translator and the others will move on to PROMISe. Once the encounters reach PROMISe, they are processed through a series of edits. Encounters will pay or deny based on which edits set. 04/02/22 4
Full File Rejects 837 Input File Acknowledgements From the HIPAA Translator An X12 TA3 Acknowledgment (ZZZ) This report is generated for HIPAA transactions when: Submission does not pass EBX security check. Full File Rejects An X12 TA1 Acknowledgment (ZZZ) This report is generated for HIPAA transactions when: Control numbers do not match between the ISA and IEA segments. An unexpected transaction set is indicated. Incomplete or incorrect enveloping (ISA, IEA, GS, GE, ST, SE segments). Functional group counts are not correct. 04/03/22 5
Full File Rejects An X12 999 Functional Acknowledgment This report is generated for HIPAA transactions when the following situations exist: a variety of errors can cause, including Invalid Sender Number Premature end of file last character in the file isn t the segment terminator. ISA segment is the only fixed length record, it must be 106 positions. The 106 bytes fixed-length ISA segment does not conform to the HIPAA standard. Control numbers do not match between ISA and IEA segments. Missing or invalid grouping of the ISA/IEA, GS/GE, ST/SE enveloping. Segments within the transaction set are out of order as defined by X12 The GS-04 field length is not correct Incorrect HL coding? Also, no dash after HL. For transaction sets containing Hierarchical Levels the HL-03 - field value is not correct for the defined HL structure. Control numbers do not match between the GS/GE or the ST/SE segments Segment counts or transaction set counts not correct Request message fails a data edit (real-time) This information as well as Trouble Shooting information is currently available in DocuShare. 04/02/22 6
Accept/Reject Report When the 837 File is successfully submitted through the translator a . txn and a . ext response will be generated. These responses let you know which encounters were accepted and which rejected at the BES translator and the rejection reason. . txn is an electronic report that provides translator results of the 837 File submitted and indicates which transactions were approved and which ones were rejected . ext is a machine-readable format of the. txn. It is a flat file that can be loaded into a system. These responses are provided within 24 hours of file submission. 04/02/22 7
Example .txn Report 04/02/22 8
Encounter Data Processing Once the 837 Encounter Data File processes through BES, it is sent to PROMISe for additional editing. It is assigned a PROMISe Internal Control Number (ICN). Encounters will pay or deny based on the information contained on the encounter, and in the PROMISe system. PROMISe edits set against Provider Information which may be reconciled through the monthly PRV416 file as well as the PRV720 file. Consumer Information provided in HCSIS and eCIS. Code Combinations as outlined in the CCRI Reporting Tool and Provider Enrollment Tool Specific data values needed to process successfully in PROMISe as outlined in Encounter Submission Notes documents Other information, such as diagnosis codes provided on the monthly diagnosis file Additional information is available in DocuShare, and questions can be sent to the Encounter Data Resource Account for clarifications. 04/02/22 9
Encounter Data Processing Internal Control Number Once the 837 enters PROMISe an Internal Control Number (ICN) is created and remains with the encounter 13-digit numerical encounter identifier that is assigned by PROMISe to identify individual encounters The ICN is unique and does not change Example: 3422060321654 Region Code RR 34 (CCR Encounter) Year & Julian Day YY JJJ Claim Sequence # SSSSSS 321654 22060 (Sequence which claim was received for the region and date) (03/01/2022) 04/02/22 10
Encounter Data Processing - Patient Account Number (PAN) Patient Account Number is assigned by the plan to the individual claim This number is the only unique identifier to track the encounter from submission through PROMISe processing back to the 837 This number is the only unique identifier to connect the encounter to the U277 response The PAN is submitted in the 837 at Loop 2300 Segment CLM01 The PAN is echoed back in the U277 in the Loop 2200D, Segment TRN02 (Claim Submitter s Trace Number) 11 04/02/22
Encounter Data Processing U277 Once the encounter is finished processing in PROMISe, an Unsolicited 277 (U277) response is created. It can be expected within 48 hours of submission of the 837 Encounter Data file. The U277 is used to notify encounter data submitters about the status of each encounter. There is a U277 Companion Guide available in DocuShare. It can provide information for the accurate reconciliation of HIPAA U277 Transactions. A CCRI Edit Crosswalk is also used to assist in the reconciliation process. 04/02/22 12
CCRI EDIT Crosswalk Example U277 Status Code PROMISeTM Edit U277 response. Edit Description/Comments 837 Type DTL/HDR Disposition Claim is a duplicate of a previously paid claim F0 5004 425 Pay/List I, P HEADER Example U277 - STC01-1 STC*F0:425*20160902**72*0*20160902 Invalid Combination for Professional EPOMS Encounter F2 718 217 Deny P DETAIL Example U277 - STC01-1 STC*F2:217*20160902**72*0*20160902 STC01-1: Claims Status Category Code STC: Information Receiver Status Information F0/F2: Represents the U277 category. Can only be F0 or F2. This field represents the status code used to describe the disposition of the edit that set. The status code is located in the STC01-1 segment F indicates a finalized encounter that has complete adjudication cycle 425/217: Represents the U277 Status Code that is returned in the STC01-2 segment. Must use the BH and CCRI Edits document to crosswalk to the edit description. 04/02/22 13
Using the CCRI EDIT Crosswalk U277 Category - These catgories tell us if the edits are informational Pay/List (F0) and do not require further action from the county or Denied (F2) which requires the county to correct and resubmit the encounter. PROMISeTM Edit - This field provides the PROMISeTM Error Status Code (ESC) that is crosswalked to the U277 Status Code found on the U277 . The PROMISeTM Error Status Code is not located on the U277. U277 Status Code - This field provides the U277 Status Code that is returned in the U277 STC01-2 segment. You must utilize the BH and CCRI edits documents to cross walk to the PROMISeTM Error Status Code (ESC) Description. Edit Disposition - This field provides the Pay/List or Deny disposition of the PROMISeTM Error Status Code (ESC). Description/Comments - This field provides a brief description of the PROMISeTM Error Status Code. 837 Type - This field represents the type of 837 for which the edit will set. "I" means Inpatient and "P" means Professional. DTL/HDR - This field provides information on the area of the claim/encounter the edit is checking. The Claim Level (Header) or Service Line Level (Detail). 14 04/02/22
Error Status Code (ESC) Supplemental Extract The ESC Supplement Extract was created to assist submitters to reconcile their U277 responses by providing a way to show which PROMISe edits set for a particular ICN. The alternative is to crosswalk the U277 Status Code to the PROMISe Error Status code using the CCRI crosswalk published on DocuShare. It is an extract of Encounters which processed in PROMISe previous day where the Paid or Denied Encounter set at least one PROMISe Error Status Code (ESC). for the Any Encounter that did not set any ESCs will not be contained in this extract. Use of this file is optional and is provided as a tool you may use to assist in interpreting the U277 and reconciling denied encounters. 15 04/02/22
Encounter Data Processing - EDI Submission Statistics Counties/Joinders also receive an EDI Submission Statistics Report after the Encounter Data file is processed. This report is a response to a processed encounter in PROMISe This response provides a summary on the number of encounters submitted and accepted at the translator. Example: edi0130X.MM.rpt.YYMMDD.HHMMSS.zip Hours / Minutes/ Seconds Constant Frequency Plan Code Year / Month / Day D = Daily W=Weekly M = Monthly edi0130 MM YYMMDD HHMMSS 16 04/02/22
SeGov SeGOV is an encryption software program that protects confidential information in transit between the submitters and commonwealth business partners Two SeGOV users are permitted per the County/Joinder. The files are sent to the County/Joinder ftp site and remain in the staging area for pick up and are deleted after 60 days. SeGOV handles all files to/from the state which includes CCRI 837 Encounter Data files CCR U277 and Translator responses Provider Files Other files that pertain to CCRI 17 04/02/22
SeGov To become an SeGOV user the SeGOV User Registration Form must be completed. Once completed the form should be sent to OMHSAS 837 Issues Resource Account for processing. All questions regarding any files should not be sent to SeGov Administration as they do not track or monitor files or trouble shoot problems with the submissions that fail. These questions should also be sent to the OMHSAS 837 Issues Resource Account for handling. 04/02/22 18
Anonymous Consumers Counties/Joinders are required to obtain accurate and complete demographic information for enrolling recipients who have received or who will be receiving services. OMHSAS recognizes that in rare and unusual situations all necessary demographic information may not be available or obtainable. Therefore, OMHSAS has established a process for reporting encounters in these situations which is outlined in our Consolidated Community Reporting Initiative (CCRI) - Use of the Anonymous Consumer MHX Recipient Identification Number document. This document is currently available on DocuShare. Anonymous consumer encounters should only be reported as outlined in this document and should not be used for reporting any other consumers. Over-utilization of anonymous consumers results in reporting anomalies and lack of substantial data. Large files of anonymous consumers force PROMISe to go through an entire pricing routine for each encounter causing the system to crash. The provider should make every possible effort to obtain demographic information, while ensuring the safety of the individual and counties/joinders should assist them and limit the use of this type of reporting. 04/02/22
Other Information All questions regarding Encounter Data, SeGov or any files sent to/from the counties/joinders should be directed to RA-PWOMHSAS837ISSUES@pa.gov. Any other questions related to CCRI should be directed to ra- pwomhsasccridata@pa.gov. New OMHSAS Website: HealthChoices Systems Management (pa.gov) which includes information for CCRI. This information is on the Internet and does not require a b account to access the information. Link to DocuShare: DocuShare Login (state.pa.us) 04/02/22 19
Conclusion Please send questions/comments regarding this presentation to RA- PWOMHSAS837ISSUES@pa.gov and we will respond as quickly as possible. All questions/answers will be shared with this group. Thank you. 20 04/02/22
