Frequently Asked Questions (FAQs) for 834 Transactions

A.

The NYSOH 834 and the eMedNY 834 are different files from different systems. eMedNY access details and business rules are published in both of the following documents on www.emedny.org in Transaction Instructions under the eMedNY HIPAA Support Tab:

• The eMedNY Trading Partner Information Standard Companion Guide in the Connectivity/Communications section
• The Managed Care Enrollment (MCE) 834 Companion Guide in the Payer Specific Business Rules and Limitations section

A.

Existing eMedNY access methods will be used to deliver the 834 file. The Default ETIN will serve as the routing mechanism for the 834 transaction files. Plans should already have a default ETIN on record, along with a USER ID for that ETIN in order to receive the 834.

eMedNY access details and business rules are published in both of the following documents on www.emedny.org in Transaction Instructions under the eMedNY HIPAA Support Tab:

• The eMedNY Trading Partner Information Standard Companion Guide in the Connectivity/Communications section
• The Managed Care Enrollment (MCE) 834 Companion Guide in the Payer Specific Business Rules and Limitations section

A.

An initial Verification (audit) file will be available for use. The Verification (audit) file will be an 834 with Maintenance Type Code 030 (Audit or Compare) in Loop ID 2000 that will provide a point in time look at the Plans current enrollment. Plans will have the option to request a full Verification (audit) file 2 times per year in addition to the initial Verification (audit) file.

A.

For eligibility discrepancy issues, plans should continue to follow the current process by working through their agency contact.

For all EDI syntax and/or HIPAA transaction compliance questions send an email to: eMedNYHIPAASupport@gdit.com

For connectivity support contact the eMedNY Call Center at 800-343-9000, or email: emednyproviderservices@gdit.com

A.

The L ("Lost") and A ("Added") files from Maximus NYMC will be discontinued. The rest of the Maximus NYMC supplemental files and reports, including the Disenrollment Report, will continue to be provided.

A.

Effectuation files are not mandatory. eMedNY will accept and process effectuation files. However, there will be no reporting of effectuations not received.

A.

Effectuation files are NOT mandatory. eMedNY will not have any editing in place to reject an effectuation. The only rejections would be violations of the HIPAA compliant syntax in the ASCX12 999 Acknowledgment.

A.

There is no requirement to perform enrollment reconciliation with this project. An initial Verification (audit) file will be available for use. Then eMedNY will provide, by request, two times per year, an 834 Verification (audit) file with Maintenance Type Code 030 (Audit or Compare) in Loop ID 2000 that will provide a point in time look at the Plans current enrollment.

A.

No, effectuations are separate from the enrollment delivery process, and they are not required.

A.

QHP is the ID that the Plans know as Plan Assigned Policy Identifier. The Plans provide the Policy ID; therefore, it would already be stored in the Plan's system. eMedNY expects to receive this ID from a Plan on the 834 - Effectuation. The next time eMedNY sends a transaction to the Plan, eMedNY will echo this ID back to the Plan. The term 'QHP' has been changed to reflect Plan Assigned Policy ID in the 834 MC Companion Guide.

A.

Plans are generally enrolled under different MMIS Provider ID's for different products; therefore, separate files for each MMIS Provider ID should be expected. If a plan has several products under one MMIS Provider ID, the clients benefit package is included in the 834.

A.

There were many differing questions received regarding how to prioritize the 834 enrollment transactions for Plan members. Because there can be many different scenarios with many different solutions, the Department has provided some business rules that should be followed in order to assist with how to prioritize more than one 834 transaction received for a member. The business rules are published in the MCE 834 Companion Guide in the section eMedNY Business Rules for Transaction Processing Sequence on www.emedny.org under the HIPAA Tab > Transaction Instructions.

A.

Plans should follow the same action they do today when receiving notification of a retroactive disenrollment. A Plan must take action based on the communication from LDSS for Death and Incarceration. The Plan will get a Term from eMedNY, but the Plan should not wait for that Term. Also, Plans will not transmit cancels to eMedNY.

A.

No, clients will retain their current CIN.

A.

The 025 (reinstatement/re-enrollment) code will not be used on the 834 MCE Enrollment File.

A.

These two dates will always be the same on the 834 MCE Enrollment File. Plans can use either one.

A.

These two dates will always be the same on the 834 MCE Enrollment File. Plans can use either one.

A.

Primary Care Physician will not be provided on the 834 MCE Enrollment File.

A.

Plans will continue to receive Last Name, First Name, Middle Initial, and Addresses (including Case Name and Care of Name) as provided on the Roster. The same processes used to determine correspondence mailing should continue. Please refer to the Managed Care Enrollment (MCE) 834 Companion Guide on emedny.org under the eMedNY HIPAA Support tab for details.

A.

Expected Date of Confinement (EDC - Due Date) will not be provided on the 834 MCE Enrollment File.

A.

The eMedNY 834 originates from, and is sourced from eMedNY. When using ePaces to verify eligibility, ePaces is also sourced from eMedNY.

A.

Neither Head of Household (HOH) nor Responsible Party are provided on the WMS Roster and will not be provided on the 834 transaction from eMedNY. The same data provided on the Rosters will continue to be provided via the eMedNY 834.

Please refer to the Managed Care Enrollment (MCE) 834 Companion Guide on emedny.org under the eMedNY HIPAA Support tab for details.

A.

Nursing Home members will appear on the 834 with the appropriate RRE code. Nursing Home Name, 8-digit MMIS ID and the Effective date(s) of the RRE codes will be included on the 834.

NAMI will be provided on the 834, as long as that amount can be determined.

Please refer to the Managed Care Enrollment (MCE) 834 Companion Guide in the section labeled -Table A - Member Reporting Category (Loop 2700) Iterations on www.emedny.org in Transaction Instructions under the eMedNY HIPAA Support Tab

A.

No, the Monthly Nursing Home Residents specialty roster will not continue.

A.

eMedNY will not use the Health Commerce System (HCS) to post the 834 file (see FAQs: L2 & L3). Existing files (except the MC rosters transitioning to the eMedNY 834 and some reports) that are generated by WMS will still be available in HCS.

A.

Plans may still receive notifications from LDSS regarding member enrollment changes. However, the eMedNY 834 should be considered the source of truth.

A.

Plans will continue to receive the same address data as provided on the Roster. The same processes used for confidential addresses should continue.

Please refer to the Instruction Tables section of the Managed Care Enrollment (MCE) 834 Companion Guide on www.emedny.org in Transaction Instructions under the eMedNY HIPAA Support Tab

Additional information on Address Confidentiality Program (ACP) for Victims of Domestic Violence may be found at: https://www.health.ny.gov/health_care/medicaid/publications/gis/15ma005.htm.

A.

There will be no monthly correction file.

A.

The eMedNY 834 will send the current rate at that point in time. Changes in rates are not a trigger for sending an 834. Rate adjustments will be communicated the same way they are today.

A.

Unborn and newborn will be sent in the 834 as an ADD transaction for both. Changing unborn to newborn will result in an 834 CHANGE transaction.

Please refer to the Managed Care Enrollment (MCE) 834 Companion Guide on emedny.org under the eMedNY HIPAA Support tab for details.

A.

If Third Party Liability Coverage is on file, it will be returned on the 834.

A.

"The dates represented by 348 and 356 will be the begin date of the current enrollment period.

Example – If a member is enrolled with a plan as of 1/1/2019 in Medicaid, but the first Verification file is sent 4/1/2020, the 348 and 356 dates on the first Verification file will be 1/1/2019.

A.

Yes - per the ASCX12 Technical Report Type 2 Reference Model each Functional Group must have its own Acknowledgement. eMedNY intends to send only one ISA and one Functional Group per file, and only 5000 transactions per file.

A.

In most cases, eMedNY will produce a single 834 per member per day that will convey an Add, Change, Term, or Cancel with some exceptions.

Exceptions are:

1. eMedNY will produce two 834 transactions (ADD followed by TERM) to report a change to a TERM transaction that was already sent to a Plan and coverage is still active (where coverage end date is greater than or equal to 834 generation date).
2. eMedNY will produce two 834 transactions (ADD followed by TERM) to report only retro coverage date changes on termed coverages (where coverage end date is less than 834 generation date and greater than the date that indicates look back period).
3. eMedNY will produce more than one 834 transaction when the member has two coverage periods (with a break in coverage) to report to a Plan.

A.

The value sent in BGN02 is the Transaction Set Reference Number. This reference number is comprised of our internally assigned File-ID (position 1-18) and a unique Transaction Control Number or TCN (position 19-34).

Please refer to the eMedNY MCE 834 Test Scenarios & Sample Files document on emedny.org under the eMedNY HIPAA Support tab. The sample data has an example of the BGN02.

A.

This detail comes directly from WMS, so it will continue to be non-standardized for the foreseeable future.

A.

Every action taken by an LDSS is noted within WMS information. Every 834 is based on an action taken by an eligibility worker.

Reach out to the county if there is an issue.

A.

The Aid Category indicates when a client is SSI and is on the 834. The appropriate rate code will also be provided on the 834.

A.

The Department has decided that it is best for these files to continue to be delivered to the Plans in the interim of transitioning to the 834s. Supplemental RRE file from HCS will be discontinued once the RRE information is included with the 834 transactions.

A.

No, the Maximus NYMC files are supplemental, and should not be used as the source of eligibility. The eMedNY 834 is the source of eligibility and enrollment.

A.

The Maximus NYMC files are supplemental, and should not be used as the source of eligibility. The eMedNY 834 is the source of eligibility and enrollment.

Follow current protocol for error resolution.

A.

The Maximus NYMC files are supplemental, and should not be used as the source of eligibility. The eMedNY 834 is the source of eligibility and enrollment.

Note: TERMs from eMedNY will run once a month on the 25th.

Follow current protocol for error resolution.

A.

Yes, this will be for all Managed Care Rosters.

A.

The eMedNY File Naming Conventions and Size Limits are published in both of the following documents on www.emedny.org in Transaction Instructions under the eMedNY HIPAA Support Tab:

• The eMedNY Trading Partner Information Standard Companion Guide in the Connectivity/Communications section
• The Managed Care Enrollment (MCE) 834 Companion Guide in the Payer Specific Business Rules and Limitations section

A.

Yes, members who move from NYC (County Code 66) to Upstate (or Upstate to NYC) are assigned new Client Identification Numbers.

A.

eMedNY uses 2 custom disenrollment codes (LPS and INC) ONLY when there is no direct mapping to 834 X12 TR3 reason codes (INS04) or a WMS Enroll/Disenroll Reason code is not applicable.

WMS reason codes will be indicated when available on all transaction types in the 2750 loop.

The WMS Enroll/Disenroll Reason Codes can be found in the Code Lists section of the MCE 834 Companion Guide

A.

Unborn and Newborns are initially communicated through an ADD transaction. Any subsequent changes will be communicated through a CHANGE transaction.

A.

A member who moves from MMC to HARP will result in two 834s being sent. The MMC will receive a TERM. The HARP will receive an ADD. It should be noted that plans may get the ADD transaction before they get the TERM.

A.

No. When HARP enrollment is received by eMedNY, an ADD transaction will be sent at any time, including before the TERM transactions on the 25th of the month.

A.

The Begin Date will be populated with the earliest begin date where the member has continuous coverage with the Plan.

A.

YES, a Reinstate will be sent as a 021 ADD transaction.

If a 024 TERM transaction is received on the 25th of the month, and subsequent to that the coverage is reinstated, a 021 ADD transaction will be sent for that reinstatement with the original begin date.

A.

The following HCS reports will NOT be produced:

• Monthly Secondary MLTC Clients with Budgets 02, 05, 06, or 07 sb1uMMYY.txt, PUPB20-ERR, PUPB20-BT07
• Monthly Secondary PCP Error Rosters mu06MMYY, mn16mmyy
• Monthly Secondary Provider Roster su08MMYY, sn18mmyy
• Daily County Benefit Package Flip Report bpucMMDD
• Daily Managed Care Enrollment and Error Report mpcea999, pupea999
• Daily One Step Managed Care Enrollment Report pupoa999
• Monthly Auto Re-enrollment/Error Reports ru42mmyy, rn42mmyy
• Monthly Auto-Disenrollment Report du96MMYY, dn96MMYY
• Monthly County Disenrollment Rosters drucMMYY, drncMMYY
• Monthly County Interim Enrollment Roster 20muMMYY
• Monthly County R/E 83 ASA Reports ASA-CNTY-99
• Monthly End of Lock-In Reports LCK-RPT-99
• Monthly Nursing Home Residents mnhuMMDD, mnhnMMDD, MNH120-MMDD
• Monthly PCP Auto Disenrollment Reports for Closed Clients du97MMYY, dn97MMYY
• Monthly PCP Auto Disenrollment Reports for Prisoners duP1MMYY, NYC to PHRED
• Monthly PCP Auto Disenrollment Reports that have OMH Suspensions duP2MMYY
• Monthly Primary County Rosters 57muMMYY, 57mnMMYY, BICS
• Monthly Primary MLTC Clients with Budgets 02, 05, 06, or 07 pb1uMMYY, PUPB10-ERR, PUPB10-BT07
• Monthly Primary PCP Error Rosters mu42MMYY, mn42MMYY
• Monthly Primary Provider LTC Surplus pltcMMYY.txt
• Monthly Primary Provider Roster 52muMMYY, 52mnMMYY
• Monthly Primary Re-Enrollment Report ru42MMYY.txt, rn42MMYY
• Monthly Provider Disenrollment Rosters drupMMYY, drnpMMYY
• Monthly Provider FIDA Disenrollment Reports UWMMYYYY, NWMMYYYY, UAMMYYYY, NAMMYYYY
• Monthly Provider Interim Enrollment Roster 10muMMYY, 10mnmmyy
• Monthly Secondary County Roster su09MMYY, sn19mmyy, BICS

A.

Member's In Care of Name will be valued when available in the N302 (Member Address Line) in Loop 2100A .

Please refer to the Managed Care Enrollment (MCE) 834 Companion Guide on emedny.org under the eMedNY HIPAA Support tab for details.

A.

Plans should follow the same action they do today when receiving notification of a retroactive disenrollment.

A.

No, Plans do not submit cancel transactions to eMedNY.

A.

There is no change to this activity. Plans can continue to use, and are encouraged to use, the X12 270 Eligibility request after the 834 Enrollment is implemented.

A.

There is no change to this activity. Plans can continue to use, and are encouraged to use the X12 276 Claim Status Request to receive an X12 277 Claim Status Response to find out the status of submitted claims.

In addition, eMedNY will continue to acknowledge the X12 837 Institutional Claim with the X12 277 Claim Acknowledgement.

A.

eMedNY is working on a future SFTP solution; however, it will not be in place before this 834 project is set to go live.

A.

Normal EDI process flow should be followed. A 999 Acknowledgment with the proper error message should be relayed to eMedNY.

A.

No change will be made to the existing process.

A.

Normal EDI process flow should be followed. In the case where the 834 cannot be processed by the receiver due to a failed syntactical analysis, then the Interchange Acknowledgement (TA1) can be sent as the response. ASCX12 has provided an outline for the scope of the TA1 and its uses: https://x12.org/index.php/resources/requests-for-interpretation/rfi-2435-ta1-acknowledgment-status-and-note-code-24

If a trading partner is unable to produce the TA1, send an email to the HIPAA team at: emednyhipaasupport@gdit.com for research and resolution.

A.

We are not changing existing processes. Standard process requires these go through local districts.

A.

eMedNY expects to receive an X12 999 Implementation Acknowledgment to ensure the X12 834 file was accepted/rejected by a Plan. There are no requirements specific to eMedNY for development of the 999 Implementation Acknowledgment; therefore, instructions specific to eMedNY will not be published. Trading partners are directed to the Type 3 Technical Report ASC X12C/005010X231 Implementation Acknowledgment for Health Care Insurance (999). This Implementation Guide is available at http://store.x12.org

A.

The system will generate a term for a loss of eligibility (e.g., incarceration), and an ADD will be sent when they return.

Refer any questions to your State contact.

A.

We will not be sending HIV SNP rate codes in the eMedNY 834 transactions.

A.

Transgender will be identified by RRE code on the 834, if the individual notified the district.

Homeless and emancipated members cannot be systematically identified for the 834. NY Medicaid Choice identifies NYC Shelter homeless to the Plans.

A.

Any change in category of eligibility resulting in a Rate Code or an RRE change triggers an 834.

A.

When submitting an 834 Effectuation back to eMedNY, eMedNY will respond with a 999 Implementation Acknowledgment.

A.

Mapping is available in the 834 Companion Guide on the HIPAA Transactions tab on www.emedny.org.

Plans may also send an email to: emednyhipaasupport@gdit.com.

A.

Yes, the client would appear on the next daily file as a retro enrollment.

A.

Renewal Date is the same as the Recertification Date and is defined as the last day of the previous month (one month before the eligibility end month).

A.

The Maximus NYMC files are supplemental, and should not be used as the source of eligibility. The eMedNY 834 is the source of truth.

A.

Maintain the current process and repay, if a repayment request is received.

A.

Yes, the Spend Down/Excess Income effective date will appear in Loop 2750. Please refer to the Managed Care Enrollment (MCE) 834 Companion Guide on emedny.org under the eMedNY HIPAA Support tab for details.

A.

There is no risk if the plans do not send back effectuations as it relates to QHP ID/Plan Assigned policy ID. eMedNY does not use this information within its processing system; it is only used to echo back what the plan provided to eMedNY on future 834 transactions.

A.

Marital Status will not be populated on the 834; eMedNY will not receive this information from the WMS.

A.

For your HARP provider number, you will receive the HARP rate code of 7580 only.

A.

Making changes to the CIN process is not in-scope for this project.

A.

The district code will be provided on the 834. Please refer to Crosswalk in the Managed Care Enrollment (MCE) 834 Companion Guide in the Payer Specific Business Rules and Limitations section on www.emedny.org in Transaction Instructions under the eMedNY HIPAA Support Tab

Plans should continue to follow the current process by working through their agency contact.

A.

No. eMedNY has no mechanism to accept a client change of address from any source but WMS.

There is no change to the current process; changes in consumer address are to be submitted to the LDSS.

A.

The telephone number will be the phone number provided to eMedNY by WMS for the member/enrollee or the "in care of" person/entity for the member/enrollee.

*field definition from spreadsheet: Phone number of person in care of enrollee*

A.

Please see the FIPS Code set in the Managed Care Enrollment (MCE) 834 Companion Guide in the Payer Specific Business Rules and Limitations section on www.emedny.org in Transaction Instructions under the eMedNY HIPAA Support Tab

A.

This is the Plan's own ID number provided to eMedNY when an effectuation is received and processed. eMedNY takes this number from the Loop ID 2300 REF when valued with the 1L = "Policy Identification Number" on the inbound Effectuation file and echoes this number back to the Plan in Loop ID 2300 REF segment with the X9 Qualifier on subsequent 834 transactions for that enrollee.

A.

For mainstream managed care (MMC), turning 21 will trigger a new Rate code, which will be sent on an 834.

A.

It depends on the access method.

For files inbound to eMedNY exchange: there are no file naming requirements; eMedNY will apply its own naming convention for the remaining lifecycle of the file.

For files inbound to FTP/VPN: Naming conventions for FTP and VPN are the same as any other file uploaded to eMedNY. Files must be compressed into a ZIP file prior to sending files to the FTP/VPN ID. Name your file as follows: Node1.Node2.Node3

Where node1 = 'P' followed by the first seven digits of your provider number (i.e. P1234567)
Where node2 always = ZIP
Where node3 = Generation/File number in the following format (G000?V00), where ? = the ordinal (1, 2, 3, etc.) of the file you are sending for the day.
Note: Using the example above, if you wished to send three files in a single day, the completed remote files would be:
P1234567.ZIP.G0001V00 (1st file for the day)
P1234567.ZIP.G0002V00 (2nd file for the day) P1234567.ZIP.G0003V00 (3rd file for the day)

For plans that will utilize the FTS/SOAP platforms, please see the User Manuals posted under the SELF HELP section on emedny.org/selfhelp/index.aspx

A.

eMedNY will not use this data element since the transaction create date and time are already in the BGN Segment.

A.

The eMedNY 834 should be considered the source of truth for eligibility.

The E-files are considered supplemental to the eMedNY 834 and will continue.

A.

You will receive the E-File the day after the eMedNY 834.

A.

Yes, the eMedNY 834 will contain the same Aid Categories plans see today in the WMS Roster. Please refer to the Code Lists section of the Managed Care Enrollment (MCE) 834 Companion Guide in the Payer Specific Business Rules and Limitations section www.emedny.org in Transaction Instructions under the eMedNY HIPAA Support Tab

A.

While the X12 834 Transaction does support the use of repeating data elements, there is a limited amount of data that eMedNY receives from the WMS. In the example given, eMedNY will only get one phone number from the WMS, so it is not possible to return more than one phone number for each enrollee. See FAQ ID L144 for additional details.

A.

The eMedNY 834s are the source of truth, and the other files are supplemental. As currently provided, the E file has primary care provider, health assessment findings, etc. We recommend that you follow your current procedures for those files.

A.

If the Plan assigns both a Group Number and a Policy Number that are different and wants to convey those ID numbers to eMedNY, then the Plan would send the following on the Effectuation:

• The Plan Assigned Group Number in Loop 2000 REF Segment, with the qualifier '1L' in REF01

AND

• The Plan Assigned Policy Number in Loop 2300 REF segment with the qualifier '1L' in REF01.

Then, on subsequent outbound 834 Enrollments for that member, eMedNY will return the following:

• The Plan Assigned Group Number with the qualifier '1L' in REF01 (Loop 2000)

AND

• The Plan Assigned Policy Number with the qualifier 'X9' in REF01 (Loop 2300)

A.

A "REJECT REASON" (Loop 2750 N102) with an Error Message Text (Loop 2750 REF02) is recommended but it is not mandatory for every "EXCEPTION" returned by the Plan on an Effectuation file. The Error Message Text for the REJECT REASON should be free-form text, conforming to the X12 834 TR3 defined field length for REF02 (Loop 2750).

A.

The values eMedNY plans to send in INS04 (Loop-ID 2000) are published in the Medicaid Managed Care Enrollment 834 Companion Guide in section Payer Specific Business Rules and Limitations > Code Lists on www.emedny.org under the HIPAA Tab > Transaction Instructions.

A.

Incarceration is the only situation where eMedNY currently values both Reporting Categories (Loop-ID 2750) with "INC" (DISENROLL RSN) and "IN" (WMS ENROLL/DISENROLL REASON CODE) on a TERM (024). Plans may use the reason codes from either of these two Reporting Categories (Loop-ID 2750) as well as the Maintenance Reason Code (Loop-ID 2000). All these codes are intended to clarify the Enrollment or Disenrollment reason and should essentially convey the same message. Although, if a Plan is limited to using only one of these reason codes, DOH Policy recommends using the WMS ENROLL/DISENROLL REASON CODES (Loop-ID 2750).

A.

The statement, "End date will be populated only on TERM transactions." has been removed with the update to the MCE Companion Guide Version 2.3.

A.

All Maintenance Types reported in the eMedNY 834 (001, 021, 024, 030) have the potential to report a Date Range (DTP02="RD8") in the DTP Segment of Loop ID 2750-Reporting Category Date, when a Reporting Category has an end date. Please see the eMedNY MCE 834 Test Scenarios & Sample Files on the eMedNY HIPAA Support tab of www.emedny.org where there are samples of the RD8 values in different reporting categories.

A.

Individuals enrolled in Long Term Care (Partial, MAP, PACE, FIDA IDD) can have a Spenddown or NAMI amount. Individuals in Medicaid Managed Care can have a NAMI, if deemed eligible.

A.

You will receive the 7580.

A.

eMedNY will send a file whenever there is activity on an enrollee. This could be as frequently as daily, and can include weekends and holidays. eMedNY will begin compiling the activity at midnight every day for the previous day's activity, and will release the files to Plans as they become available.

A.

eMedNY will not send an ADD and CANCEL 834 transaction if both are done the same day. We would only send an ADD and TERM if they were done on the same day. We could send an ADD and CANCEL if they were sent on different days.

A.

Making changes to the CIN process is not in-scope for this project.

A.

The TPHI information included on the 834 transaction does not eliminate the requirement for notification to the LDSS.

A.

Yes, we have been communicating these changes with LDSS MC coordinators. Districts should continue to work with Plans to resolve WMS-enrolled cases through approved communication.

A.

After go-live, Verification files will be requested through Tier 2 Operations by emailing emednyproviderservices@gdit.com
Plans can contact Tier 2 Operations for the following:

• Request a Verification File twice yearly
• Submission for technical support

NOTE: For Verification File requests, please use the subject Verification File Request.

These details can be found in the 834 MCE Companion Guide under Request for additional Verification (Audit) Files

A.

Plan Assigned Policy Identifier is optional on effectuations. If the Plan sends an effectuation file, eMedNY will echo back the Plan Assigned Policy Identifier the Plan sent in Loop-ID 2300 REF-MEMBER SUPPLEMENTAL IDENTIFIER segment with the qualifier '1L' in REF01.

A.

At the current time, this process will remain outside of the 834 process.

A.

For MMC, there should be edits to prevent this. Do not reject transactions, but notify your contacts if this does occur (using the steps necessary to report that the member can be disenrolled).

For MLTC clients, the above answer does not apply; please follow your normal guidelines.

A.

If Third party insurance company has a Non-NAIC carrier code in the eMedNY system, this code will be concatenated with the carrier name (Ex: "COB Payer [H9999]") and populate it in NM103 segment.
COB*U*1923000000000001*1~
DTP*344*D8*20190901~
NM1*IN*2*EMPIRE PLAN / STATE EMPLOYEES[EM]~

If Third party insurance company has an NAIC carrier code in the eMedNY system, this code will be sent in NM109 segment.
COB*U*1923000000000001*1~
DTP*344*D8*20190901~
NM1*IN*2*COMMERCIAL INSURANCE NAME*****NI*95222~

A.

Change transactions will have all the information for the member in each change transaction.

A.

If there is an empty income loop, it indicates the excess income is removed.

A.

Yes, the change transaction can have excess income.

A.

Yes, this is correct.

A.

HIOS ID is not on the roster now, and therefore will not be provided on the 834s from eMedNY.

A.

This field is not available on the 834. Plans can still utilize an Eligibility transaction, either in ePaces or a 270 X12 Request/271 X12 Eligibility Response, to get the member's LDSS Office Code.

A.

For this population, please use the following Aid Categories:

• 82 Medicaid Buy-In-Disabled Basic Group (FP)
• 83 Medicaid Buy-In-Medically Improved (FP)

A.

This value will not be on the 834; Plans should always assume this will be '03'.

A.

There is no guarantee date on the roster now. The field is blank (the title is there).

A.

eMedNY will not be sending the Authorization Date on the 834. However, Plans will receive a RECERT DATE.

The exception to this will be members who are SSI – this case type will not have a recertification date populated.

A.

That is correct. The transactions will be daily, so the use of a Transaction Date would be redundant. Client transactions are accumulated each day until midnight, and then the eMedNY 834 is generated. The Transaction Date will be the previous day's date.

A.

(*) is a new enrollment line on the roster (never in that plan before). An ADD could be totally new or a reinstatement. Still need to send welcome packet. May have been a gap in enrollment.

A.

Code values 05 and 06 are auto-assignment; code 07 is automated, not auto-assigned.

A.

Per the ASCX12 834 Implementation Guide, entities can return up to 5 sets of COB data.

A.

There can be multiple people with the same Case Name and Case Number. There will be no changes to the WMS Case Name/Case Number process.

A.

There are no name normalization rules that the counties follow for populating this data element. The data entered here varies; there is no way for eMedNY to know what is a first name, a last name, a facilty name, or any number of other entity types that the LDSS will populate in this data element.

A.

eMedNY will not be populating the N3/N4 data elements in Loop-ID 2100G for Case Name. Member addresses are already passed in Loop-ID 2100A (Residential Address) or 2100C (Member Mailing Address).

A.

That is correct; the MCE Companion Guide Version 2.4 has been updated to reflect that the Care-of Name can be valued in both locations.
Guidance is as follows:

• Care-of Name will be populated on residential address (2100A, N302) when member has only one address or when member residential and mailing address is the same.
• Care-of Name will be populated on mailing address (2100C, N302) when member residential and mailing address is different.
• Care-of Name will be prefixed with literal "C/O".

A.

SSI individuals are on their own case with a separate Case Number/Case Name from other household members. The SSI case, if a child, will be in the child's name, not the parent's name. The 834 transactions will not change this process.

A.

This is not currently provided via the roster process and will not be provided via the 834. There will be no change to the rate code process for the SNP population.

A.

Maximus receives daily updates from eMedNY. Maximus sends Plans enrollment information after confirmation from eMedNY that the enrollment was accepted.

A.

The mention of Maximus as a source has been removed from the MCE Companion Guide Version 2.4.

A.

Any reference to "834" in the eMedNY 834 MCE Companion Guide will only be referring to an eMedNY 834.

A.

The Rate Code begin date will be included on the 834 transaction within Loop 2750 DTP Segment.

A.

The initial Verification File will be provided to Plans at go-live to kickoff the 834 process. This Verification File will replace the Roster for the month of go-live from a specific date forward, including prospective enrollment. This Verification File meets the Plan request to begin the 834 transaction set with a full-file of enrolled members that the Plan is responsible for serving.

A.

eMedNY has no plans to accept or process any proprietary error files produced by the plans.

Plans are highly encouraged to respond to eMedNY with an Effectuation to relay rejections.

A.

Auto-Assignment is indicated with values 05 or 06 on the Reporting Category Loop 2750 (N102=WMS ENROLL/DISENROLL REASON CODE), or you can use value AL on INS04 segment to indicate "Auto-Assignment".

AL will appear in INS04 for ADD (021) transactions, as well as CHANGE (001) transactions, if the member has reason code 05 or 06 on the eMedNY system.

A.

While not part of the 834 process, and in addition to the normal rate correspondence from the Rate Setting Bureau, eMedNY has a report that can be generated for all Rate-based providers once every six (6) months for each MMIS ID. Please fill out the form: Request for Provider Reports (#610901) on www.emedny.org under the Provider Enrollment Tab, Provider Maintenance Forms.

A.

When the MCO sends the U file to Maximus, Maximus sends the file to eMedNY the same day. eMedNY sends a confirmation to Maximus and the 834 to the Plan the following day.

A.

Given there are different MMIS IDs for each product, when a member moves from one to the other (example HARP to FIDA), eMedNY will send an 834 TERM transaction for the HARP MMIS ID and will also send an 834 ADD transaction for FIDA MMIS ID.

If a Plan has multiple files over multiple MMIS Provider IDs, eMedNY has no mechanism in place to be able to sequence these files across multiple MMIS Provider IDs.

BGN02 can be used by plans in sequencing multiple files and multiple entries for a client on the 834 for each MMIS Provider ID.

A.

When a case number changes, eMedNY will send an 834 CHANGE transaction.

The effective date of the change can be determined by using the "Maintenance Effective Date" populated in the DTP segment of Loop 2000, with qualifier '303' as an effective date of case number change.

Any change that occurs after the first (1st) of the month, should be effective the first (1st) of the following month.

A.

There is no process at eMedNY to detect rate code changes and send an 834 transaction based solely on those changes. However, when eMedNY sends an 834 transaction for any reason, eMedNY will derive the current rate code and populate it on the 834 transaction. The Rate Code begin date will be included on the 834 transaction within Loop 2750 DTP Segment.

A.

Plans should load (or process) the data from the initial verification file eMedNY sends at the time of go-live the same way Plans load the data from the WMS Rosters today. Plans can use subsequent verification files (verifications files sent after initial verification file) for reconciliation purposes.

With the initial verification (030) file, there should not be any expectation to receive prospective enrollments as new ADDs.

After go-live, if a verification (030) file is requested, it is possible that Plans might already have received the ADD transaction for the prospective member on the daily file.

A.

If there is no member activity for a plan on a specific date, there will be no 834 generated for that day. eMedNY will not send blank or empty 834 files.

A.

eMedNY does not have a way of sending notifications when files are sent.

A.

There is no intention for DOH to implement Name Normalization Rules that the counties will follow when populating Case Name and C/O Name. eMedNY will pass along what LDSS enters into WMS.

For standard Postal Addressing, Plans are encouraged to contact the United States Postal Service (USPS) for guidance.

A.

Per Policy guidance, unborns and newborns without date of birth and gender information will no longer be issued a default rate code (2200) on the eMedNY 834; the rate code field will not be valued. The rate code information will be sent once date of birth and gender information are updated in the eMedNY system.

A.

Terminations will be sent by type. For example, deceased members or members whose managed care coverage/eligibility is end-dated retroactively will be sent daily.

Members whose managed care coverage/eligibility is lapsed or end-dated within the current month will be reported on the 25th of the month.

eMedNY generated 834s will not send Terminations 45 days in advance like NYSOH 834s.

Future Terminations will not be reported until the 25th of the month when the end date falls in that month.

A.

No, eMedNY will not be populating default rate codes. Once the date of birth and/or gender is provided to eMedNY from WMS, a Change transaction will be generated, and the rate code will be derived and provided to the Plan. If a MLTC plan receives an ADD transaction with a newborn, the Plan should report the issue to MLTC staff as an enrollment error.

A.

No, eMedNY will not be populating default rate codes. eMedNY will provide the rate code according to the logic provided by the Department. If there is incorrect/mismatched information on a Mainstream Managed Care member, the Plan should reach out to the LDSS for review of the case. If there is incorrect/mismatched rate code on a MLTC member, the Plan should report the issue to MLTC staff and use the rate codes issued by Rates until advised otherwise.

A.

eMedNY is not receiving any information from WMS to indicate it is a renewal transaction for a member. So, there is no data available to send Maintenance Reason Code "41 - Re-enrollment" on the eMedNY 834 transactions to indicate it is a renewal transaction.

A.

A member that has a lapse in eligibility for the upcoming month will be identified to the plan via the Terminator process. This process will run on the 25th of the month.

On the eMedNY 834 TERM transactions, these will be identified with LPS indicator in loop 2750 using the literal DISENROLL RSN.

N1*75*DISENROLL RSN~
REF*ZZ*LPS~

A.

The rate code change is effective for the first of the following month. The Rate Code begin date will be included on the 834 transaction within Loop 2750 DTP Segment.

A.

A Care-Of Name Change would be a trigger for sending an eMedNY 834 Change transaction. Therefore, the Transaction Date would be the effective date. This will be found in the DTP Segment, indicated by '303' = Maintenance Effective Date in LOOP 2000.

A.

When eMedNY receives notice from WMS that a case is closing for Death, eMedNY will send an immediate 834 TERM transaction to plans with Maintenance Reason code 03-DEATH.

If WMS does not send a Date of Death, we will populate it with a default date of 99991231 on the 834 transaction, since the date is situationally required by the X12 Implementation Guide.

If WMS sends eMedNY a Date of Death before the coverage expires at the end of the month, eMedNY will send an ADD transaction, followed by another TERM transaction on the same day with the actual Date of Death WMS provides.

A.

eMedNY does not receive an indicator from WMS regarding a member's veteran status. There is also no code set to indicate this on the X12 834 Transaction itself.

If this indicator is needed, Plans should continue to utilize the UAS-NY assessment, or current resource used today.

A.

When a member has a gap in coverage, this also changes their case number.

Because of that, the 834 changes their Effective Date to the start of the new case, with the new case number.

WMS still relates the new case to the old case and continues the original effective date.

A.

Yes, the HCBS K codes will be included along with the other RRE codes.

A.

Plans need to look at the dates in the business rules (4.2.6 eMedNY Business Rules for Transaction Processing Sequence).

An 834 ADD transaction with a future begin date will be applied regardless of source and/or preexisting coverage from another source.

An 834 ADD transaction with a begin date in the past will be applied when there is no coverage from another source.

If a client is actively enrolled due to coverage from another source, to process the ADD transaction (with begin date in the past) from a second source, follow your current process.

Plans are also encouraged to verify eligibility via ePACES or their own 270/271 transaction.

Finally, when in doubt, reach out to the contact source from the last enrollment transaction.

A.

If members are enrolled in a plan in WMS, the plan will be getting an eMedNY 834 with the corresponding rate code when the process is turned on.

A.

The scenarios for the NAMI/EXCESS dollar amounts are:
When one of the two amounts is greater than zero, the other amount is always zero. Or both the amounts can be zero.

The following are possible combinations (Note: the fifth combination is very rare)

1. Sending NAMI & EXCESS amounts for single time period.
2. Sending NAMI & EXCESS amount combinations for different time periods.
3. Sending message (NAMI/EXCESS MSG) for single time period.
4. Sending NAMI & EXCESS amounts for one time period and message (NAMI/EXCESS MSG) for another time period.
5. Sending NAMI & EXCESS amounts for different time Periods and message (NAMI/EXCESS MSG) for different time periods.

A.

The E and T files come from Maximus. These files will continue, so Plans will continue to receive this supplemental information from Maximus.

The listing of Maximus files which will be discontinued can be found in FAQ L94.

A.

Continue to follow the MMC contract guidelines to ensure newborns are enrolled. If the newborn has not been updated via DOH, please contact the enrollment source (LDSS or NYSOH).

A.

eMedNY will send retroactive enrollments and/or retroactive terms immediately upon receiving the information from WMS.

Please refer to FAQ L238 for additional scenarios regarding Term transactions.

A.

When 2100G NM101 contains 'QD', the most recent CASE NAME will be valued in the NM103 field.

Please note that eMedNY passes the value here exactly as received from WMS and the CASE NAME is not always intended to identify the person/entity responsible for the member. Plans may continue to use the CASE NAME in the same manner as when it's received on the monthly Rosters.

A.

eMedNY will be publishing an update to the Roster-to-834 Crosswalk section of the MCE 834 Companion Guide. Because a change to most of the fields listed will trigger an eMedNY 834 being sent to the plans, the update to the CG will add a note indicating which fields will not result in an 834 being sent.

A.

The LDSS and NY Medicaid Choice business processes should not change due to the implementation of the 834 transaction set. With the change to a daily delivery method of enrollment information, Plans will receive new information on a daily basis.

A.

eMedNY will make the files available for Plans to retrieve daily by 6:00 AM.

Plans will only received 834 files if there are transactions for that plan for that day. Contact emednyhipaasupport@gdit.com for any questions.

A.

After go-live, plans should receive their daily 834 files by 6AM. However, if there are no transactions for the plan for that day, there will be no file to send.

If there is a system issue that will affect delivery of the daily 834 files, eMedNY will send a ListServ notice advising of the delay.

If there is no ListServ notice, and a plan has not received a file by noon, the plan should presume there are no transactions for the plan for that day.

A.

Yes. The transactions in the eMedNY 834 will be sequential based on the value in the BGN02 data element.

A.

There are two scenarios where there is a possibility of sending multiple transactions for the same member:

Scenario 1 - Gap in coverage
For example, if a member has two coverage periods associated with the same plan in the eMedNY system, one coverage period is from 4/1/2020 to 5/31/2020 and another coverage period is from 7/1/2020 to 6/30/2021. There is no coverage for 1 month (i.e. June 2020). Following are the scenarios that explain what type of 834 transactions are created.

1. Let us assume, WMS sent second coverge period (7/1/2020 to 6/30/2021) to eMedNY on 5/5/2020. The system will create the following transactions on 5/5/2020:
a. A TERM transaction with coverage start date as 4/1/2020 and end date as 5/31/2020.
b. An ADD transaction with coverage start date as 7/1/2020.

2. Let us assume, WMS sent second coverge period (7/1/2020 to 6/30/2021) to eMedNY after 5/25/2020 (TERM Process). The system will create the following transactions:
a. ADD & TERM transactions with coverage start date as 4/1/2020 and end date as 5/31/2020.
b. An ADD yransaction with coverage start date as 7/1/2020.

3. Let us assume, WMS sent second coverge period (7/1/2020 to 6/30/2021) to eMedNY after 5/31/2020 (TERM Process). The system will create the following transactions.
a. An ADD Transaction with coverage start date as 7/1/2020.

4. Let us assume, on 5/15/2020, WMS/Counties noticed a gap and they removed that gap in member coverage and sent a transaction to eMedNY. After processing the WMS transaction, there is a continuous coverage (4/1/2020 to 6/30/2021) in the eMedNY system. On 5/15/2020, the system will create the following transactions:
a. A CANCEL transaction with coverage start date as 7/1/2020.
b. An ADD Transaction with coverage start date as 4/1/2020.

Scenario 2 - To communicate changes for a member to whom we already sent a TERM transaction.
For example, if a member has coverage from 10/1/2019 to 09/30/2020. In this scenario, we sent a TERM transaction to you on 9/26. Let us assume, some information is changed for this member on 9/27. To communicate this change we will send an ADD transaction followed by TERM transaction.

A.

If the plan receives a retroactive enrollment, plans should enroll the member and reach out to the LDSS to confirm the enrollment.

A.

eMedNY will send an 834 ADD transaction for each newborn child. If they are initially sent as unborn, changing to newborn will result in an 834 CHANGE transaction.

A.

The Benefit begin date is the effective date, and the Effective Date for Deemed New Born(s) is the first of the month of birth.

A.

The Rate Code begin date will be included on the 834 transaction within Loop 2750 DTP Segment.

A.

If the eMedNY 834 fails EDI Validation, the Plan would send the appropriate reject reason in the 999 response file. eMedNY will then investigate and correct the cause of the EDI Validation failure.

Future 834 files would be stopped depending on the nature of the error.

Plans will receive regenerated file(s) once the corrections have been made.

Transaction sequencing will be maintained through the use of the BGN02.

A.

The 11-digit MBI indicates Medicare Beneficiary ID.

The 16-digit Other Payer Policy Sequence Number is always 16 digits, and indicates third party commercial coverage.

The COB02 is intended to tie the reporting category to the COB loop. Review the examples on page 44 of the Companion Guide to show how to associate the two.

A.

Plans may use the reason codes from either of these two Reporting Categories (Loop-ID 2750) as well as the Maintenance Reason Code (Loop-ID 2000). All of these codes are intended to clarify the Enrollment or Disenrollment reason and should essentially convey the same message. Although, if a Plan is limited to using only one of these reason codes, DOH Policy recommends using the WMS ENROLL/DISENROLL REASON CODES (Loop-ID 2750).

A.

The Plan TPL reporting process will not be impacted by this project. Plans should continue to follow their current processes.

A.

Yes. The OMIG process for the Restricted Recipient File will not be impacted by this project.

A.

Plans will need to email their requests for the biannual Verification files after go-live. eMedNY does not have any plan at this time to automatically schedule these additional Verification files.

Verification files will be requested through Tier 2 Operations by emailing emednyproviderservices@gdit.com

NOTE: For Verification File requests, please use the subject Verification File Request.

These details can be found in the 834 MCE Companion Guide under Request for additional Verification (Audit) Files

A.

Dual Default members will have the new 2196-2199 rate codes, but there will not be a specific RRE code indicator for these clients.

These members will be on the same 834 files as the regular MMC or HARP clients.

A.

For MLTC, continue to follow current process until advised otherwise.

A.

No, 95 is a disenrollment reason code. LPS indicates lapse of coverage. A member will not have both an Enroll/Disenroll reason code of 95 and LPS.

A.

There was a coding issue which caused this. The code will be changed to populate ""AC"" Active in the INS08 data element for 834 Audit transactions. The fix will be promoted to production on December 24, 2020.