Massachusetts Frequently Asked Questions (FAQs) for the Collection of Commercial Claims Data

 

  1. Massachusetts has a December 1, 2007 due date for historical production files. What is the timeline for deliverables and testing between now and then?
    Since the contract signing on October 16, 2007, MHIC has been working on the necessary updates to the system to accommodate testing of carrier files by early November. The system will be available to receive test data no later than November 15, 2007. The detailed timeline for testing and submission of the historical data is part of the statistical plan and includes the registration of carriers, assignment of carrier IDs and notification back to the carriers, carrier level encryption testing and necessary receipt of certain coded data element definitions (i.e., provider specialty codes and if necessary "Home Grown" or local procedure or diagnosis codes) .
  2. Is there a plan to allow for technical questions in the future?
    MHIC staff are available to answer questions via email, conference call or face to face meeting. At any point a carrier can contact MHIC with technical and/or compliance questions by sending an email to Mainfo@ncdms.org. A MHIC staff member will respond and arrange for the appropriate follow up. In addition to one on one communication, a quarterly newsletter will be created to inform all carriers of general technical and compliance status and other topics of interest. Newsletters will be distributed via email and posted on the web site.
  3. What is the timeline and content of the statistical plan?
    The contract requires the statistical plan be presented to the Massachusetts Health Care Quality and Cost Council (Council) for review and acceptance by October 31, 2007. Once accepted the statistical plan will be released to all identified carriers and interested parties and posted on the web site. The statistical plan will include:
    • Data encryption description
    • System start up time line
    • Data collection regulation
    • Data submission instructions including submission time line and submission formats
    • Instructions for testing data and submitting historical data
    • Data quality standards including data element loading and data quality editing thresholds
    • Description of assignment of unique member ID
    • Data warehouse data dictionary

 

  1. Are denied claims required to be submitted?
    In general denied claims are not to be submitted in any of the claims extracts. However, there are issues that complicate this general regulation. There are primarily two types of denied claims: a) where the entire encounter with a provider is denied (e.g., the encounter occurred before or after a member's coverage period, the service was not a covered benefit under the member's benefit structure) b) some but not all of the service lines are not covered within a claim (e.g., the service line for a surgical tray is denied because it is included as part of the payments made for the surgery procedure line itself). In the examples above, the claims for encounters that are totally denied will be excluded and claims with mixed covered and not covered services will include only the service lines for the covered services.

    If a carrier processes global claims (e.g., a particular surgery for a hospital is paid under a global fee regardless of the member's complications and/or length of stay resulting in only the first line of the claim containing any paid dollars and all other detail service lines are "denied"), all of the claim lines in the global claim should be submitted to the MHIC.

    If a carrier has no responsibility/liability for a service that was rendered under the member's benefit structure then the claim/claim lines should be excluded. If the carrier has responsibility to cover a particular rendered service, but some covered services appear to be denied because of processing and payment structures in place then those claims/claim lines should be included in the extract.
  2. How should prescription drug services rendered within a medical claim be represented?
    Any prescription drug services that are rendered as part of the medical claim should be included in the medical claim file and be represented using an appropriate revenue code (MC054) and/or J-code reported in the CPT field (MC055). It is understood that for prescription drug claims identified through a revenue code will not have an associated NDC code to indicate the specific drug dispensed. Also, it is understood that these claims/claim lines will not be present in the prescription drug claims.
  3. What is my submitter code?
    The MHIC submitter codes, also known as the payer code, payer ID, carrier ID, etc., will be assigned and sent to you once your organization has registered with the MHIC. For the Commonwealth of Massachusetts the format of a submitter code will be a 7 or 8 character value with the first two characters being 'MA' - state code, the third character is a value of either 'C' or 'T' or 'G' where C represents a commercial insurer, T represents a TPA and G represents a government payer like Medicaid or Medicare. The next four characters will be an assigned number with the 8th position reserved for a suffix to distinguish reporting systems within a carrier.
  4. The regulation mentions that HEDIS and CAHPS files are to be submitted, how and when?
    MHIC is not responsible for the collection of HEDIS and CAHPS data for the Commonwealth of Massachusetts. However, as information becomes available regarding those requirements, we will pass that along.
  5. What are going to be the steps for collecting race and/or ethnicity data?
    The Council is working on a plan to determine the best method for a carrier to be able to report this data. A series of meetings will be held by the Council to explore this issue. Although the race, ethnicity and Hispanic indicator fields do not need to be populated until July 2008, they may be reported now in the file formats. If it is not available, the fields should remain null. We will report on the quality and completeness of any data in these fields but we will not fail any submissions due to poor quality or incomplete race or ethnicity data until the fields are required.
  6. Is there a method to submit late claims paid during a prior submission period?
    Yes there is; however, the MHIC wants to limit these types of submissions to a minimum as it complicates transferring data to the State. Basically, if a carrier identifies to the MHIC a block of data that should have been included in a monthly paid data submission that has already been accepted by the MHIC but for one reason or another it was omitted, then the MHIC will issue a temporary submitter code with a new suffix to that carrier. The carrier will use this temporary code to submit the previously paid data and the MHIC has a process in place that once this special data submission has been accepted the data will be migrated to the proper submitter code. If a carrier's original submitted file has yet to be accepted by the MHIC then the carrier will be requested to re-submit both the data from the original data submission and any new data identified in one file. Also please read the FAQ on how do I determine what should be included.
  7. How do I determine what data should be included in a monthly claims file?
    The monthly submission of claims data from a carrier to the MHIC is termed a "Paid Claims Dataset". To verify that the data is a submission is being accurately selected the MHIC uses the Header record begin and end dates formatted as YYYYMM and in each detail record we use fields - Medical MC017 & Pharmacy PC017 - Date Service Approved (AP Date). The MHIC verifies that each date supplied in fields MC017 and PC017 are between the header records begin and end date timeframe. For a single month submission the header record would contain the same value in both begin and end date fields. Now, what data field should be used to populate fields MC017 and PC017? There are a number of potential values that could be used to populate these fields, but whatever value is used needs to be consistent within a carrier from month to month, otherwise we run into problems with either missing claims for a certain time period or receiving duplicate claims for a certain time period. As a basic regulation the date field that should be used to populate these two data elements is the date field that is used by the carriers extract program to determine what data should be included in a given months data submission. That means that is the true paid date is used to select records for inclusion in a file than the paid date values should be placed in these fields, but if a data warehouse update/load date is used to select records for a data submission then that date value should be used to update these data elements. We have found through working with carriers submitting data for Maine and New Hampshire that any of the following fields could be employed for selection and inclusion of data: Claim Paid Date, Claim Accounts Payable Date, Check Cut Date or Warehouse Update/Load Date, but in any case once a method has been selected by a carrier we do not want the carrier to later change the value that they are using.
  8. Should dental claims be included at this time?
    No stand alone dental products should be reported at this time. The scheduled implementation date for dental data is September, 2008. Council staff are conducting meetings to develop a data collection format for the dental data. MHIC will share that information as it becomes available.

    Please note that any dental services that are paid as part of a medical benefit/claim would be included in a carrier's standard medical claims submission. For example, if a member has an accident that requires facial and dental reconstruction and the payments falls under the member's medical coverage, all services rendered and paid for under the medical plan would be submitted in the carrier's medical file.
  9. Should vision claims be included?
    If the vision service is a covered medical benefit (e.g., the member over 18 who can receive one eye exam at a participating eye care specialist once every two years) it must be submitted as a medical claim. Unless it is a covered medical benefit, MHIC should not receive any claims for eye care products, such as prescription eye glasses, contacts, solution, etc. Any prescriptions covered under a member's prescription drug benefit would be included in the pharmacy claim submission.
  10. What lines of business are to be included? Are Medicare, Medicaid, FEP and Commonwealth Care excluded?
    Medicare, Medicaid, and Commonwealth Care lines of business are not required to be submitted. Under the provisions of the regulation 129 CMR 1.09 section (7) Regulations Governing Claims Submissions paragraph (l) Medicare, Tricare or Other Supplemental Health Insurance are to be excluded unless a covered service under these policies are entirely excluded by Medicare, Tricare or other program.

    Products where Medicare is the primary payer should be excluded. Products where the carrier is the primary payer listed on the claim, such as Medicare wrap around and/or complementary products are required to be submitted. Products covering an FEP or Tricare population are not required under the rule but can be submitted and will be accepted if a carrier includes them in their standard data submission. Carriers planning to submit for an FEP or Tricare population should confirm this with the MHIC staff before submitting.
  11. Why do some of the coded values differ across file types? Why do some code values not have a value to represent unknown?
    Although the HIPAA standard coding schema was adopted for the coding structure within the Massachusetts claims regulation, the HIPAA electronic transmission coding standards are not standard across the different file types. Therefore, the prescription drug specifications call for gender codes of 1, 2 or 3 while the medical and eligibility specifications require a gender code of M, F or U. This follows the HIPAA requirements for these data sets. Please use caution when setting up your extract to code all of these fields appropriately. Similarly, if a coded field does not have a value to indicate "unknown" it is because HIPAA did not allow for an unknown value to be reported. In a few instances only a subset of the HIPAA codes are allowed in the extract. This was done to restrict the use of non-specific codes.
  12. What provisions are in place to ensure data confidentiality, particularly with regard to sensitive diagnosis (HIV/AIDS) and procedures (abortion)?
    Through the use of the encryption software all direct PHI data elements are encrypted through a one-way hashing function before they leave the carrier, so the identification of members having sensitive diagnosis or procedures performed should not be in question. Provisions for protecting the release of sensitive conditions and procedures will be determined by the Council. MHIC is only responsible for the collection of the data and providing a complete, edited data warehouse to the Council. The use and dissemination of that data is governed by the Council.
  13. Can you help us understand what the data inclusion regulation is actually saying?
    The Regulation Clarification and examples below are preliminary and are subject to change after final review by the Council. However, for testing purposes please follow the clarification listed below to determine what data you should include and what data should be excluded from your data submission. A carrier (defined as a fully funded at risk insurer) that does not meet the requirements for submission exclusion as defined in the Massachusetts regulation - Chapter 129 CNR by premium level or membership level is required to submit data to the contracted entity. The requirement for exclusion is for carriers with less than $250,000 in accident and health insurance premiums in Massachusetts on an annual basis or plans covering fewer than 200 Massachusetts residents in total. Currently under the current regulation, a third party administrator (TPA) is not required to submit data to the Commonwealth but may do so on a voluntary basis. Due to the very short time frame for bringing the system on line and collecting the historical data, TPAs will not be allowed to submit data before February 2008.

    The requirement for reporting data for fully insured business is based on the location of the policyholder and the eligible's location of residence. If the policyholder is a Massachusetts business or resident then all claims and eligibility data must be reported for all Massachusetts residents covered under that policy. In this example, the policyholder is considered to be the employer/business or individual that contracts directly with the carrier to obtain health coverage services. Under this definition the following examples lists situations where the data would or would not be required in a data submission.
    • Example 1: A local non-national Massachusetts business contracts with a carrier for health benefits, but has employees living in Massachusetts, Maine and New Hampshire. Only data for the Massachusetts residents belonging to this company will be submitted.
    • Example 2: A national business with headquarters in Massachusetts contracts for health benefits/policies for all of its employees nationwide through its main office in Massachusetts. Only data for the Massachusetts residents belonging to this company will be submitted.
    • Example 3: A payer directly offers individual health benefits to residents of Massachusetts and their families and/or small businesses. All of the data for these individual and covered members under the policy is required to be submitted if their residences are located in Massachusetts.
    • Example 4: A company/business with its headquarters located in another state (e.g., Maine, Arkansas) has chain stores/operations/employees in Massachusetts, but issues health care benefits/policies from a location outside of Massachusetts. This data is NOT to be submitted for any of the covered lives including those with residency in Massachusetts.
    • Example 5: As in example 4 above, a company/business has its headquarters located in another state; however, the particular chain store or operations located in Massachusetts contracts in Massachusetts for the health benefits for the employees located in Massachusetts and/or other states. Any covered lives under such a policyholder are required to be submitted under the regulation for all members with a residency in Massachusetts.
    • Example 6: A labor union, employer association or coalition offers health benefits to its members and the association's headquarters is not located in Massachusetts. Therefore, because the policy is issued outside of Massachusetts the data for these policies would not be required to be submitted. However, If the association was located in Massachusetts and the policy was issued in Massachusetts, all members data would be required to be submitted if their residency is in Massachusetts, even if an out of state health benefits broker was employed by the association.

If you are uncertain and have a scenario that does not fit within one of the six examples above please contact us at mainfo@ncdms.org and we will work with you to determine if the data for said policyholder is required or exempt. We will also continue to add examples of new scenarios to this list over time.

  1. If certain fields are unavailable when we submit data, but later become available will we need to resubmit everything?
    The data layouts currently accommodate all known required data elements, including the race, ethnicity and Hispanic indicators that are not required until July 2008. A carrier must provide all required data elements appropriate for the data set and the time period at the time of submission. Completeness thresholds have been established for each data element and are documented in the statistical plan. Submissions with data elements failing the completeness threshold for one or more fields will be rejected in their entirety. A carrier unable to meet the completeness threshold due to restrictions within their system will be referred to the Council for a decision on how to proceed.
  2. Our membership eligibility data is based on a start and end month. Can we report it to the MHIC in that manner?
    No. The eligibility data is submitted in a monthly format with one record for each covered life eligible for one or more days of services during the reported month. Each eligibility record in a given month's file will represent one active member with all reported data elements representing either the status as of the end of the reporting month or as of the premium billing date. For the required historical data feeds carriers will submit one record per member per month of active coverage during the 15 month period. For the historical data, MHIC is requiring that each month of eligibility data be submitted in a separate monthly file.
  3. If the coverage level code of a member changes during the month, which coverage level code do you want - the first, the last or all of them in a given month?
    The status code for the coverage level field in the eligibility file should be as of the end of the month or the applicable code for when the premiums were billed for that member during the month. This same regulation applies for all the other data elements in the membership file, such as the employer group/policy number, member zip code, etc. In all cases, only one value should be reported in a membership record and only one membership record should exist for a member each month.
  4. Our internal coded values differ from the regulation and do not directly map, what do we do?
    Any internal carrier coded values that do not directly map to coded data element values within the regulation will need to be evaluated on a field by field basis. Please email us at mainfo@ncdms.org and list the regulation data element field number in question as well as the values and descriptions that you have available to map. We will work with you to assign the values as accurately as possible.
  5. Do we include a member identifier in the plan specific contract number field (ME007, MC007, PC007)?
    No. It is common for a carrier to have a member identifier or sequence number attached to the end of the subscriber contract number sometimes separated with an asterisk (*) or other value. The combination of these two values represents the member's full identification number. In this situation, the regulation calls for you to submit the plan specific contract number that would be used to identify all members of a family (subscriber and dependents). The sequence number should be placed in the member sequence number field (ME009, MC009, PC009) and the asterisk or other delimiter is ignored.
  6. We cannot break our provider name information into separate fields, is this acceptable?
    When the provider name CANNOT be separated into first name, last name, middle name and suffix data elements, then the entire provider name should appear in the "Service Provider Last Name/Organization Name" field. This should only be done as a last resort.
  7. In our system we do not use a version number to identify adjustments. What do we do?
    If a carrier's processing system or data warehouse does not use a record versioning method to identify adjustment records for a claim, then the version number field should be defaulted to a value of 0. This will be acceptable as long as any reversal and/or adjustment records are reported in such a way that a given claim line can have all of its versions identified and consolidated together so that the result is one claim line for an incurred service processed over a given paid date range with the correctly summarized dollar values. As part of the follow up to the carrier registration, we will be asking the carrier to explain in English terms and examples how the Council would take the carrier's submitted paid dataset and convert the claim lines into an incurred dataset for a given paid date range resulting in correctly summarized dollars. This information will be passed on to the Council.
  8. How should we report multiple E-Codes on a claim?
    If a given claim contains multiple E-Code values in the diagnosis fields then the first E-Code encountered in the processing of the claim should be loaded into the E-Code data field (MC040) in the extract submission. All other E-Codes in other diagnosis fields should be listed in the Other Diagnosis code fields (MC042-MC053) after all other regular ICD-9 diagnosis codes have been listed. An E-Code should never be listed in the primary diagnosis data field (MC041).
  9. How should we report multiple revenue codes or procedure codes listed on a single claim line?
    The MHIC is acquiring examples of how this can happen. We do understand that on a hospital/facility claim a given claim line may have both a revenue code and a Procedure/CPT code. In that instance the revenue code is reported in MC054 and the CPT code is reported in MC055. It is unclear how a single claim line can have multiple CPT codes or multiple revenue center codes assigned to it unless one code is the original billed code and one is the modified payment code based on contracting changes made by the carrier. If the later is true MHIC staff will work with you to arrive at a solution.
  10. Should text fields be padded with blanks and should numeric fields be padded with zeros to their maximum length?
    No padding should occur. Although the record layouts list a maximum length that will be accepted, the submission is designed to be variable length. No text field should be blank or space padded on either the right or left and the numeric fields should not be zero padded to the left of a value. If this is done, it can cause your transfer rate to slow down. Even though the file to be transmitted is compressed, there is still space used to represent the blanks, spaces and zeros and, in a large data file, this additional space could be substantial enough to lengthen the transfer time. Also, if the fields to be encrypted have been blank/space padded then the encryption routine may fail (if the whole field is blank) or may not properly encrypt the value.
  11. We sell products across state borders in New England and therefore have members that may have changed state residence over time. We only keep the latest subscriber address for a given subscriber and their dependents. Therefore, if a member living in New Hampshire in November 2007 moves to Massachusetts in December 2007 and we pay claims for that member in December 2007 with an incurred date in November 2007 or prior what do we do with these claims?
    We recognize that this issue exists. We would want to see those claims submitted rather than put the burden of eliminating those claims from the file on a carrier. This policy will result in claims records with no supporting eligibility records in our database for November 2007. We will evaluate the prevalence of claims unsupported by eligibility data on an ongoing basis and determine if they should be dropped from the database at a later date. The MHIC feels this is the best current solution rather than ask you, the carrier, to try and determine if and when the address of a subscriber changed from one state to another.
  12. What is meant by the Insured Group or Policy Number (ME006, MC006, PC006)?
    The Insured Group and/or Policy Number is the employer group or account number(s) for the contracted employer. There may be one or more of these numbers for a given employer group according to how your system is set up. Furthermore, if your plan writes individual policies, this number would be the actual policy number unless your system uses the subscriber's identification/contract number for an individual policy number. In that situation, the individual's insured group or policy number should be reported as "INDIVIDUAL".
  13. What about payer-specific provider specialty codes, procedure codes, and diagnosis codes?
    There is a provision in the regulation to have all carriers submit a spreadsheet of all carrier assigned provider specialty codes with their descriptions. The spreadsheet should contain the provider specialty code and a definition of the code. MHIC also requires a spreadsheet that contains any home grown or local procedure or diagnosis codes with their corresponding descriptions. Failure to provide the local codes could cause your medical claims submissions to fail for the inclusion of procedure and diagnosis codes that are not recognized by the system.
  14. How do the Data Load and Data Quality Edit thresholds work?
    Based upon the review of existing claims databases, standards have been established for the quality of the data to be submitted. In the data load, each data element has been assigned a minimum percent completeness threshold. In general the data element's completeness is evaluated by the total number of valid entries divided by the total number of records submitted. However, for some data elements, the denominator is a subset of the data because of the nature of the data element. The specifications for calculating each data element's threshold and the statewide number for that data element are documented in the statistical plan. Failure of a submission to meet one or more of the completeness thresholds will result in the automatic failure of the submission.

    Similarly, the data quality edits are designed to evaluate the content of the data submitted and frequently involves the comparison of two or more data elements. The data quality thresholds represent the maximum tolerance for data issues. The data quality specifications and the tolerance thresholds are documented in the statistical plan. Failure of a submission to stay below one or more of the data quality edits will result in the failure of the submission.

    It is understood that system restrictions may prevent a carrier from meeting all of the data tests. In those situations, MHIC will work with the carrier to document the source of the problems to present to the Council for a temporary or permanent exemption. All such deviations from the statewide quality standards must be approved by the Council.
  15. Are we to include the procedure code (MC055) as it was submitted or as it was paid?
    If you have the ability to re-code CPTs based on claims processing and standard CPT coding logic, then the CPT included in the file should be the CPT tied to the actual payment dollar amount.
    Medical file example:
    • MC055 - CPT Code of procedure as paid
    • MC062 - $ amount of submitted procedure (billed charges)
    • MC063 - $ amount of paid procedure

In this example the CPT codes for the dollar amounts listed in MC062 and MC063 could be different and the actual CPT code that is submitted would be the one tied to the dollar amount listed in MC063.

  1. In the pharmacy file layout you are asking for the charge amount. Our system does not have that value. What should we do?
    The amount/value of this data element should represent the fully loaded cost/charge of the pharmaceutical dispensed. It should contain at least the Ingredient Cost/Billed Amount (PC037), the Dispensing Fee (PC039), any administrative fee and any applicable tax.
  2. There are two things that you can do to make the transfer as secure as possible:

1.      Use the SSL certificate to insure that the web site you are connecting to is, in fact, the web site that you are supposed to be connecting to. When connecting to the secure portion of the NCDMS web site (user services including encryption utility software download, data file upload, and data submission reports), you should see an icon of a locked golden padlock along the bottom of your browser window. By clicking on this icon, the certificate can be viewed. You should examine the certificate and make sure that the certified network address, organization name, and organization location are what they should be (secure.mhic.org, Maine Health Information Center Inc, Manchester, Maine, US) and that the certificate date range is valid. If this information is not valid, or if you see the icon of an unlocked golden padlock along the bottom of your browser window, you should contact us before proceeding.

2.      Use the highest supported level of encryption when transmitting data to us. There are two levels of encryption that are supported by the SSL standard (50-bit and 128-bit). Some web browsers support only the lower level of encryption (50-bit). Our web server supports higher level 128-bit encryption but will negotiate with the web browser that is asking for a connection and will drop down to the lower level 50-bit encryption if that is all that your browser can support. The 128-bit encryption is significantly harder to crack than the 50-bit and if you are concerned about security, you should make sure that the browser you are using supports 128-bit encryption. You can check this by clicking on the help option in Internet Explorer and going to the "about Internet Explorer" drop-down menu option. On the pop-up screen, there will be an entry titled "cipher strength" which will say either 50-bit or 128-bit. If your browser is using 50-bit encryption, you can download the 128-bit version of Internet Explorer at no cost from Microsoft.

 

  1. What is the transmission time frame for the data?
    In general, data must be filed by the last day of the month for the previous month's activity. Therefore, on April 30, 2008, data for March 2008 must be submitted. Carriers with 2,000 or more covered Massachusetts lives must submit monthly and begin submitting in 2007. Carriers with 200-1,999 covered Massachusetts lives will start submitting data in 2008 and assume a quarterly submission schedule are the historical data is in. Due to the large amount of historical data, the monthly submission schedule will not start until 2008. Please refer to the statistical plan or the web site for the start up schedule through March 2008. For the first wave of larger carriers, the historical submission requirement is to be sent to the MHIC by December 1, 2007.
  2. Whom do I contact if I am having upload problems?
    For general transmission, technical or data questions or for web upload questions please contact mainfo@ncdms.org and your question will be routed to an appropriate staff member for a response.
  3. Do we have to use the asterisk (*) as the field separator in the files? What if a text value contains an (*) within it?
    The use of the asterisk (*) as the field separator is a HIPAA standard and a regulation specification requirement and MUST be used to separate each field within the required files. Although, not specifically stated in the regulation, it is perfectly valid to enclose any or all text/alpha fields within double quotes - ex: "abc". If a text value that is required actually contains an (*) as one of the characters then that field MUST have double quotes around the entire value - ex: "ab*cd". It is not acceptable to have a double quote embedded in any text value. If double quotes exist in your incoming data (generally found in Drug Name (PC027)) they must be removed prior to submission of the data.
  4. There is something wrong with the encryption software. I can't get it to work. What should I do?

 .        Download the sample data files from the web site and run those through the encryption software. If this does not work, email us at mainfo@ncdms.org.

a.       Check your data for imbedded asterisks in the data values. These must be enclosed in double quotes.

If the above do not correct the problem, email us at mainfo@ncdms.org.

  1. How are Type of Bill - MC036 and Site of Service - MC037 related?
    These two data elements are mutually exclusive. Type of Bill (MC036) should only be available for hospital/facility claims (claims from the UB 92/04 forms or 837 HIPAA facility transaction set) and site of service (MC037) should only be available for professional claims (claims from the HCFA-1500 forms or 837 HIPAA Professional Transaction set). NCDMS looks for the combination of these two fields to be filled in 100% of the time and are critical data elements for the system's determination of denominator values to perform Load and DQ edit threshold checks.
  2. How will I find out if my submission failed?
    All registered contacts for a carrier will receive emails from NCDMS for submissions automatically failed by the system. The email will briefly explain the reason for the failure. The details of problems associated with the data can be viewed by logging on to the system and looking at the system entries associated with that submission. Emails may also be sent by MHIC staff to the contacts for data quality issues. These emails are customized and contain specific information about the problems identified. An email initiated by MHIC staff often results in opening a dialogue between the carrier and the MHIC staff.
  3. Will MHIC be signing confidentiality agreements with the individual plans and data submitters?
    MHIC will not be signing agreements with the individual submitters. The Massachusetts Health Care Quality and Cost Council has the statutory authority to compel the collection of this data and will serve as the agency responsible for safeguarding its contents and use. Since MHIC is functioning as an agent of the Council, no signed agreements are required.
  4. What are the most common mistakes made when submitting data?
    Any of the following can cause the submission to be rejected.

 .        Wrong relationship code (ME012, MC011, PC011). HIPAA standards call for different code values for eligibility data vs. claims data. For example, the employee is coded as 20 in MC011 and as 18 in ME012.

a.       Wrong product code (ME003, MC003, PC003). HIPAA standards call for different code values for eligibility data vs. claims data. For example, indemnity insurance is coded as IN in ME003 and as 15 in MC003.

b.      Low paid to charge ratio in claims data (MC063 : MC062). This is generally because the payer has failed to code the product as Medicare (MC003 = MA, MB) or failed to code the claim status as secondary (MC038 = 02).

c.       Claims unsupported by eligibility data. In general over 95% of the claims incurred for a given month should be supported by eligibility data submitted for that same month. This does not happen when the member identifiers are not reported exactly the same way in the eligibility file and in the claims file.

d.      Invalid and missing procedure codes. If a payer accepts local CPT codes and does not provide those codes and their associated descriptions to the MHIC, records with those local codes will be flagged as in error. If the payer makes payments directly to members and there is no procedure code information, a dummy code must be entered in the CPT Field (MC055). We recommend a code of MBR. If the plan pays for prescription drugs through the medical plan and no NDC code or J-Code or revenue code is available, a dummy code must be entered in the CPT Field (MC055). We recommend a code of DRUGS. If you use codes other than those recommended, you must report those to us.

e.       Invalid diagnosis codes. Payers must report all valid characters of the ICD-9 diagnosis code. Some payers collect only the first 3 characters. This will cause the submission to fail. Decimal points must not be included in the reported diagnosis code.

f.        Too many members associated with a single contract. This is generally an eligibility file problem caused by reporting the group or policy number in the contract field (ME009). When populated, ME009 should be unique for the subscriber. This field must not be submitted with all 9's, 0's, etc. If the subscriber's social security number is provided, this field can be blank.

g.       Average age over 65. It is highly suspicious to see a submission with an average age over 65 and the product code not set to Medicare. Such a submission will fail until corroborated or corrected by the carrier.

h.       Missing provider information. Provider information is required for all medical claims. If payments are made to the member, an entry still must be made in the provider last name field (MC030), the provider specialty field (MC032) and in the service provider number field (MC024). All records must have a service provider number, service provider name and a service provider tax ID. Failure to provide this information will cause the submission to fail.

i.         Mixed signs in a single record. Positive dollar amounts are not to be preceded by a + sign. We expect all adjustment records with negative dollars amounts will have all dollar fields as well as the quantity or unit fields coded as negative. If your system adjudicates claims in such a way that a line item may have both negative and positive records, you will need to explain this to us or the submission may fail.

j.        Dates out of range. The HDR and TRL records specify the earliest and latest dates submitted in the file. For eligibility data this relates to year and month (ME004, ME005), for medical claims date service approved (MC017) and for pharmacy claims date service approved (PC017). A submission with one or more records outside the date range on the HDR and TRL records will be rejected.

k.      Invalid file format. A file submitted with the wrong number of data elements (too few or too many) for the data type will be rejected. A file submitted with alpha data in a numeric field will be rejected.

 

  1. For the Site of Service field (MC037), we cannot distinguish ambulance land (41) from ambulance - air or water (42). How should we code our ambulance claims?
    Code them as ambulance - land (41)
  2. Table 13 - Discharge Status on page 34 of the regulation contains many more codes than those listed as valid for discharge status in Table 16 - Medical Claims File Layout. Which table contains the correct code values?
    The larger, more inclusive code set listed in Table 13 contain the valid codes that may be submitted.
  3. How are new codes authorized by CMS but not included in the regulation to be reported?
    Any valid CMS codes may be reported for a data field. Please contact Madata@ncdms.org with new values you intend to use before submitting the data. This will allow us to add the values to our reference tables to prevent your submission from failing.
  4. Should students be reported in the eligibility and claims data?
    Yes, if they are permanent residents of the Commonwealth of Massachusetts.
  5. How do we report a student in the Individual Relationship Code (ME012, MC011, PC011) field?
    Students should be coded as 19 - Child. We recognize that students can be as old as 26.
  6. How do we report a disabled dependent in the eligibility field Individual Relationship Code (ME012)?
    If the student is < 18, code the member as 19 - Child. If the student is > 18, code the member as 34 - Other Adult.
  7. What is the relationship between medical claims fields Type of Bill (MC036) and Site of Service (MC037)?
    These fields are not mutually exclusive. Type of Bill (MC036) should only be populated on UB facility claims and Site of Service (MC037) must be populated on professional claims. Site of Service (MC037) may also be reported for facility claims.
  8. For the medical claims field Site of Service, we cannot distinguish Residential Substance Abuse Treatment Facility (55) from Psychiatric Residential Treatment Center (56). How should we handle this?
    Use the diagnosis codes to distinguish between the two codes. If a patient has both a substance abuse diagnosis and a psychiatric abuse diagnosis on the claim, code the claim according to whichever of those appears first.
  9. If the subscriber's name (ME901, ME902, ME903, MC901, MC902, MC903, PC901, PC902, PC903) is the same as the member's name (ME904, ME905, ME906, MC904, MC905, MC906, PC904, PC905, PC906), do both sets of name fields (subscriber and member) need to be populated?
    Yes. The subscriber name and the member name should always be populated.
  10. Is it acceptable to have different versions of the city name (ME015, MC014, MC033, PC014, PC022) such as East Boston, E Boston for the same zip code (ME017, MC016, MC034, PC016, PC024)?
    Yes, that is allowed.
  11. We do not collect country (MC035A) for our providers. How should we report this?
    If the provider's zip code field (MC035) contains a valid US zip code, enter USA in the country (MC035A) field.
  12. We would like to submit eligibility and claims data for our ASO, self funded and/or ERISA plans. Do these need to be submitted with a separate submitter code?
    No, these eligibility and claims data may be submitted with your fully insured data. However, we will need a table containing the group (ME006, MC006, PC006) numbers that correspond to these ASO, self funded and/or ERISA plan data so that they can be identified.

 

  1. We pay a lot of case rate and/or global rates on certain types of claims, how are they to be reported?

Many carriers have reported case rate or global claims with the total paid amount for the claim being reported on only one line of the claim with a claim status = 1 (paid as Primary) and all other detail claim lines are listed with an associated charge amount and no paid amount.  The subsequent detail claim lines are usually listed with a claim status = 4 (denied service line).  We understand that this is a function of your claims processing system.  However, from a research and reporting perspective, all services rendered under this type of provider agreement are considered covered services.  Therefore, it would be preferable to have all detail claim lines reported with the same claim status value as the claim line that actually contains the payment information. 

The Council staff has agreed to accept any test files and any historical data submissions with the data reported as it is in your system, as described above.  However, they reserve the right to re-evaluate this issue in the future and make changes to how this data is reported.

  1. I was just notified that my file failed, how long do I have to address the issues?

A stated in the regulation, you will have 10 business days from the time of notification that a file has failed at some point in the process.  This ten day window is a one time period to address the identified issues in one of the following manners: 1) The identified issue is corrected and a new updated data file is submitted that shows the issue as resolved or 2) the MHIC and/or the Council staff have been contacted and an approved action plan with specific dates has been identified to resolve the outstanding issue/s.  If the identified issue is corroded and new problems are introduced, the original 10 day time period is retained as the correction period.  If, at the end of 10 business days, the data issue(s) have not been resolved and/or an approved action plan is not in place, the issue will be turned over to the Massachusetts Health Care Quality and Cost Council for possible action.