Go Live – Feb. 1, 2023
As part of Ohio Medicaid’s Next Generation program, the EDI transaction process will be streamlined. Trading Partners will exchange all EDI transactions through a single connection to the Ohio Department of Medicaid (ODM) fee-for-service (FFS) program and those transactions destined for ODM’s Medicaid managed care entities (MCEs). This approach simplifies the EDI process by eliminating multiple connections for Trading Partners exchanging EDI transactions. To that end, the following changes will be necessary:
|
This initiative being implemented by ODM will mean Trading Partners will only need to maintain their ODM Trading Partner IDs rather than multiple Trading Partner IDs and connections across many payers. |
EDI Connectivity
To help facilitate connectivity with Deloitte, each Trading Partner must complete the steps as indicated in the "Connectivity Form" as part of the onboarding process to the new EDI system. This detailed information is required to establish connectivity between ODM/Deloitte and the Trading Partner for Secured File Transfer Protocol (SFTP) and/or secure web services (HTTPS).
Trading Partners who want to use the Deloitte EDI web application to manually upload/download EDI transactions will be required to log in through the InnovateOhio Platform (IOP). Each person within the Trading Partner organization will need to have their own OH|ID for access. See the OH|ID Account Creation User Guide under “For More Information” at the bottom of this page.
WEDI SNIP Edits
The Workgroup for Electronic Data Interchange (WEDI) developed the Strategic National Implementation Process (SNIP) edits to enable EDI users to verify EDI transactions in an industry-standard manner.
- Type 1: EDI syntax integrity testing – X12 or NCPDP syntax requirements.
- Type 2: HIPAA syntactical requirement testing – HIPAA Implementation Guide (IG) / TR3 requirements.
- Type 3: Balancing – Field and summary totals, financial balancing.
- Type 4: Situation testing – HIPAA IG / TR3 situational testing.
- Type 5: External code set testing – Validate and ensure proper usage of external codes.
- Type 7: Trading Partner-specific testing – HIPAA requirements that are specific to Medicare, Medicaid, Indian Health, and non-HIPAA Trading Partner-specific “business-to-business” testing.
ODM’s current translator only employs SNIP levels 1-4. Our future EDI solution will add SNIP level 5 to the following transaction sets:
SNIP 5 CODE SET LISTING
| ECS ID | External Code Source Name |
|---|---|
| 22 | States and Provinces |
| 130 | Healthcare Common Procedural Coding System |
| 131 | International Classification of Diseases, 9th Revision, Clinical Modification (ICD‐9‐CM) |
| 132 | National Uniform Billing Committee (NUBC) Codes |
| 133 | Current Procedural Terminology (CPT) Codes |
| 134 | National Drug Code |
| 135 | American Dental Association |
| 139 | Claim Adjustment Reason Code |
| 229 | Diagnosis Related Group Number (DRG) |
| 230 | Admission Source Code |
| 235 | Claim Frequency Type Code |
| 236 | Uniform Billing Claim Form Bill Type |
| 237 | Place of Service Codes for Professional Claims |
| 239 | Patient Status Code |
| 240 | National Drug Code by Format |
| 244 | Codes identifying the nature of insurance coverage (Line of Business) |
| 284 | Nature of Injury Code |
| 411 | Remittance Advice Remark Codes |
| 477 | All Patient Refined Diagnosis Related Groups (APR-DRG) |
| 507 | Health Care Claim Status Category Code |
| 508 | Health Care Claim Status Code |
| 663 | Logical Observation Identifier Names and Codes (LOINC) |
| 682 | Health Care Provider Taxonomy |
| 716 | Health Insurance Prospective Payment System (HIPPS) Rate Code for Skilled Nursing Facilities |
| 886 | Health Care Decision Reason Code - These codes communicate the reason for the health care services review outcome (278 response) |
| 896 | International Classification of Diseases, 10th Revision, Procedure Coding System (ICD-10-PCS) |
| 897 | International Classification of Diseases, 10th Revision, Clinical Modification (ICS-10-CM) |
| EAPG (for outpatient similar to DRG) |
The following payer-specific SNIP type 7 edits will also be enforced. (PACDR for MCE encounter submissions only.)
| Edit | Description of Edit | Transaction(s) |
|---|---|---|
| Subscriber Validation | Reject the claim if the subscriber ID is invalid/not known. | 837 |
| 270, 276, 835, 271, 277, 834, 837 P/I/D | Use the Luhn algorithm to ensure ALL NPIs are valid. Any NPI in any Loop with NM108=XX | 270, 276, 835, 271, 277, 834, 837 P/I/D, 278, 277CA |
| Billing Provider Validation | Reject the claim if the billing provider is invalid/not known. | 837s, including PACDR version |
| Rendering/Attending Provider | When sent, reject the claim if the rendering (attending for 837I) provider is invalid/not known. | 837s, including PACDR version |
| Billing Provider/Pay-to and Rendering Provider Affiliation Check | When there is a rendering provider on the claim, ensure that the rendering provider is affiliated to the billing/pay-to provider per ODM business rules and policies | 837s, including PACDR version |
| Billing Provider Direct Affiliation | When there is NOT a rendering provider on the 837P and 837D claim AND there is NOT an attending provider on the 837I claim, ensure that the billing/pay-to provider is affiliated to themselves | 837s, including PACDR version |
| 837 P/I/D | If Loop 2010AA does NOT contain an NPI in the NM109, verify Loop 2010BB contains a valid/known 7-digit ODM-assigned provider ID in the REF02 with the “G2” qualifier | 837s including PACDR version |
| 837 P/I/D | Reject transactions that contain BOTH an NPI in the 2010AA and a REF with the G2 in the 2010BB loop | 837s, does NOT apply to PACDR Encounter data |
| 837 P/I/D | Reject transactions if secondary NPI is invalid | 837s, including PACDR version |
Any EDI transaction which does not pass the SNIP level validations will receive the appropriate X12 response transaction (999, TA1, and/or 824).
Changes are being implemented for ALL Trading Partners. The implementation of the Next Generation program provides ODM, Trading Partners, and our Next Generation MCEs the time needed to validate systems and processes to ensure readiness.
Trading Partner Identification Number (TPIDs)
If a Trading Partner has multiple TPIDs (one for ODM and one or more for each MCE), Trading Partners will only use their existing seven-digit ODM-assigned TPID when submitting EDI transactions.
For ODM FFS transactions, Trading Partners will continue to use MMISODJFS as the Receiver ID. Each MCE will be assigned a Receiver ID and transactions will be routed according to the MCE Receiver ID. See Section 7 of the Companion Guides for a list MCE Payer IDs to be used.
What actions should Trading Partners take to prepare?
Testing and Timelines
Trading Partner testing will be conducted in the ODM Ohio Medicaid Enterprise System (OMES) Certification/testing environment. ODM encourages Trading Partners to take advantage of this testing opportunity to confirm that their EDI transactions will continue to process through the new OMES EDI solution.
Trading Partner testing for connectivity to the new OMES EDI began in February 2022. Voluntary end-to-end testing for all Trading Partner's will be from Oct.17, 2022 through Nov. 18, 2022.
Companion Guides
Companion guides are currently available on the ODM Trading Partner website at the ODM link: Companion Guides. Please be sure to check the site for any changes that may arise before the Feb. 1, 2023, go-live date.
OMES EDI Trading Partner User Guide
A new OMES EDI Trading Partner user guide will be available and posted at the Medicaid link: Enrollment and Testing. A communication will be sent out when it is ready and available to Trading Partners.
Support contacts
If you have any questions about this notification, please contact the EDI Support team by email at: OMESEDIsupport@medicaid.ohio.gov
We appreciate your cooperation and look forward to our continued partnership.