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

  1. What is the encryption process?
    The encryption application is a web start desktop application written by the Maine Health Information Center (MHIC) that can be downloaded from the www.ncdms.org web site. The encryption application serves three basic functions:
    • To perform basic text file level validation, i.e., checks the header record count with the number of detail records, checks the correct number of fields in each record, validates payer ID between data records and header record, etc.
    • To encrypt, using a one-way industry standard hashing function, all direct PHI identifiers put into the data file (these include the subscriber and member SSN values, subscriber contract ID and subscriber and member name values).
    • To create a zipped output file with a standard naming convention that is easily identified during the uploading of the file to the MHIC.

 

  1. Should we encrypt values before putting them into our extract file?
    No, the web start encryption algorithm will encrypt all values. Pre-encryption of any of the values being extract for inclusion in a file is not acceptable. Pre-encryption of any data element before running the file through the downloaded encryption software eliminates the possibility of tracking a member across payers. Any carrier pre-encryption of values in a file may cause MHIC's encryption process to fail a submitted file.
  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. 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.
  4. 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 state's claims requirements, 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.
  5. Our membership eligibility data is based on a start and end month. Can we report it 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.
  6. 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.
  7. 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.
  8. What if some of the data being required is not available within our data warehouse?
    In general, all data elements that can have an appropriate blank/null value have been identified in the layouts for the individual files. However, it is understood that there are limitations within different processing and data warehouse structures and any required data elements that you identify to us as missing or unavailable will have to be addressed on a case by case basis. Required data elements that can not be submitted must be approved by the appropriate state officials before the submission can be accepted.
  9. 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 in the extract submission. All other E-Codes in other diagnosis fields should be listed in the Other Diagnosis code fields after all other regular ICD-9 diagnosis codes have been listed. An E-Code should never be listed in the primary diagnosis data field.
  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 padded the fields to be encrypted with spaces/blanks to the right (or left) of the value to the field's maximum length. Is this acceptable?
    No, this is not acceptable. The encryption software will do one of two things:

1.    If the field is all blanks/spaces with no valid characters then you will get an error message that the field did not contain any valid characters.

2.    If the field does contain a valid value with blanks/spaces padded onto the end then those blanks/spaces will be encrypted as part of the member's SSN or contract number. This causes problems when trying to find unique members across the state if one insurer submits the data with padded blanks/spaces and then the member changes to a new insurer that does not pad the field with blanks/spaces the member's encrypted values will not match. Padding the SSN or the contract number will require the data to be re-submitted.

 

  1. We stripped off the leading zeroes from the SSN before running it through the encryption software. Is this acceptable?
    No, this is not acceptable. This causes problems when trying to find unique members across the state if one insurer submits the data with padded blanks/spaces and then the member changes to a new insurer that does not pad the field with blanks/spaces the member's encrypted values will not match. Removing leading zeroes from the SSN will require the data to be re-submitted.
  2. What is meant by the Insured Group or Policy Number?
    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".
  3. What is meant by the Plan Specific Contract Number and how is it different from the Subscriber's Social Security Number?
    These two elements may be the same if the insurer uses the social security number to uniquely identify the coverage for the subscriber and all dependents. In that instance, the plan specific contract number should be blank and only the subscriber's social security number should be submitted.
  4. 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.
  5. The member's date of birth is not always known/tracked in our system at the time of enrollment. Is it acceptable to leave it blank if unknown?
    Depending upon the Load completeness requirements for the state for which you are reporting data, this may cause your submission to fail.
  6. The Claim Status field contains a code of "04 Denied". However, the state requirements indicate that "Denied claims shall be excluded from all medical and pharmacy claims file submissions….only the fully processed/paid service claims shall be included as part of the health care claims data set submittal." Can you explain when the 04 option will be used?
    The denied code option is listed for two reasons:

0.    If one or more service lines within the claim are denied in combination with one or more service lines that were not denied then we would want to see all lines for the claim with the appropriate status code.

1.    If a previous submitted paid claim was later reprocessed and some or all or the claim lines were denied then we would need to see that claim appropriately coded so that the original paid dollars will be balanced out of the database tables.

 

  1. 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 state or commonwealth.
  2. In the 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, the Dispensing Fee, any administrative fee and any applicable tax.
  3. Are there ways to determine if our transmission is as safe as possible? What are the details?
    There are two things that you can do to make the transfer as secure as possible:

0.    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.

1.    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. 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".
  2. How do I report a double quote in a data value?
    Double quotes may not be reported as a data value. A submission containing a double quote for any purpose other than enclosing a data value will fail. If double quotes exist in your incoming data they must be removed prior to submission of the data.
  3. 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.

 

  1. Where do I populate capitated services?

Estimated FFS Payments for capitated services should be reported in the Prepaid field (MC064).

 

  1. Are workers’ compensation claims to be reported?

No, workers’ compensation claims are not reported.

 

  1. What does the message “Error: date out of range.” mean from the encryption software?

The encryption software checks to ensure that the dates specified in the HD record HD005 (Begin Date) and HD006 (End date) encompass the data in the file.  The message indicates you have submitted data outside the range of the HD record.  For eligibility data we verify that the Year (ME004) and Month (ME005) are within the begin and end dates.  For claims data we verify that the AP Date/Paid Date (MC017, PC017) are within the begin and end dates.  Your submission may also fail if you use the wrong format for the dates in the HD record.  The format must by YYYYMM as indicated in both the regulation and the documentation.

 

  1. What is meant by the Plan Specific Contract Number and how is it different from the Subscriber’s Social Security Number?

These two elements may be the same if the insurer uses the social security number to uniquely identify the coverage for the subscriber and all dependents.  In that instance, the plan specific contract number should be blank and only the subscriber’s social security number should be submitted.  If the plan specific contract number is required to be submitted it is to be reported at the subscriber level and not the individual person level.

 

  1. The Inclusion Rule says to include all paid claims, please define what is meant by ‘Paid Claims’.

A paid claim is any claim that has been processed during a given month regardless of whether the claim results in an actual payment to a provider or member except for the specific exclusions identified in the rule.  A carrier does not need to submit any identified fully denied claims or suspended/pending claims where the final outcome of the claims has not yet been determined.  Carriers must submit all adjustment records that are used to offset previously submitted claims and newly created payment claims.

Example: A claim is 100% paid by the carrier in January and then in March the claim is both “backed out” (a negative offset claim is created) and a new claim is created to split the payment of the service to 80% carrier liability and 20% member liability.  For January the carrier must submit the original paid claim where all of the payment was made by the carrier.  Then in the March paid data file the carrier must submit both the adjustment claim with negative values to back out the original claim payments and quantity amounts and the new payment claims with the paid dollars reported appropriately for the carrier and member fields.