Below are frequently asked questions (FAQs) that cover a wide range of issues regarding both New Hampshire's collection process and the particulars of coding and submitting data to the State's collection vendor, Milliman, Inc. Further details can be found by visiting the Milliman NH CHIS website (https://nhchis.com), the data solution used to collect New Hampshire's data.

The questions below have been grouped into the following categories for users' convenience:

• General
• Hashing
• Transmission
• Data
• Data Definition
• Data Submission Requirement Clarification

General

Why do we have to submit this data
This data must be submitted for insurers to be in compliance with RSA 420-G:11 and New Hampshire Chapter Ins 4000 New Hampshire Chapter Ins 4000, the legislative rule establishing the process for submitting data to the New Hampshire's Uniform Reporting System for Health Care Claims. Milliman is an agent for the state of New Hampshire and is authorized to receive these data.

How will I find out if my submission failed?
All designated contacts (based on carrier registration) for a payer will receive emails from Milliman for submissions automatically failed by the system. The email will explain the reason for the failure. The details of problems associated with the data can be viewed in the file status notification email.

Emails also may be sent by Milliman to submitters' contacts for data quality issues. These emails are customized and contain specific information about identified problems, often resulting in a solution-focused discussion between Milliman and the payer.

What are the most common mistakes made when submitting data?
The most common mistakes that can result in submission rejection include:

1. Padded spaces at the end of field values. A field with padded spaces could cause the length to be greater than the maximum length. If this occurs, the file will fail with a catastrophic failure.
2. The field has the incorrect format. For example, if a field is defined as an integer and the field contains a string, the file will fail with a catastrophic failure.
3. Relationship code is wrong for ME012, DC011, MC011, PC011. HIPAA standards call for different code values for eligibility data and claims data. For example, Employee is coded as 18 in the eligibility data (ME012) but as 20 in the claims data (DC011, MC011 and PC011).
4. Product code is wrong for ME003, DC003, MC003, PC003. HIPAA standards call for different code values for eligibility data and claims data. For example, indemnity insurance is coded as IN in the eligibility data (ME003) but as 15 in the claims data (DC003, MC003, PC003).
5. Low Paid Amount to Charge Amount ratio in claims data. This generally occurs when the payer has failed to code the product as Medicare (DC003, MC003, PC003 = MA, MB) or failed to code the claim status as secondary (DC031, MC038, PC025 = 02).
6. Claims unsupported by eligibility data. In general, more than 95 percent 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 Social Security number or plan-specific contract number is not reported exactly the same way in both the eligibility file and in the claims file.
7. Invalid and missing procedure codes. If a payer accepts local CPT codes and does not provide those codes and their associated descriptions to Milliman, records with those local codes will be flagged as errors. If you make payments directly to members and you have no procedure code information, you must enter a dummy code in the CPT field (MC055). We recommend a code of MBR. If you pay for prescription drugs through the medical plan and no NDC code is available, you must enter a dummy code 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.
8. Invalid diagnosis codes. Payers must report all valid characters of the ICD-10 diagnosis code. Some payers collect only the first three characters. This will cause the submission to fail. Decimal points are not to be included in the reported diagnosis code.
9. 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 plan-specific contract field (ME009). When populated, ME009 should be unique for the subscriber. This field must not be submitted with all 9s, 0s, etc. If the subscriber's Social Security number is provided, this field should be blank.
10. 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 payer.
11. Missing provider information. Provider information is required for all medical claims. If payments are made to the member, something must be entered in MC030 (Service Provider Last Name or Organization Name), in MC032 (Service Provider Specialty), and in MC024 (Service Provider Number). All records must have a service provider name, service provider specialty, and service provider number. Failure to provide this information will cause the submission to fail.
12. Mixed signs in a single record. Positive dollar amounts are not to be preceded by a plus sign (+). We expect that 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.
13. 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 (ME004) and Month (ME005). For claims data, this relates to Date Service Approved (DC017 in the dental claims data, MC017 in the medical claims data, and PC017 in the pharmacy claims data). A submission in which one or more records contains one of these dates with a value that falls outside of the date range on the HDR and TRL records will be rejected.
14. Incorrect number of data elements. A file submitted with too few or too many data elements will be rejected. A file submitted with alphanumeric data in a numeric field will be rejected.
15. Orphaned Claims. A small percentage of claims are expected to be orphaned however when a large percentage of claims are orphaned, this is due to a mismatch between the enrollment record and the claim record. For example, to avoid orphaned medical claims, ME009 + ME010 should match MC008 + MC009. Often, payers will be required to correct and resubmit files to resolve high occurrences of orphaned claims.

Do we have to use the asterisk (*) as the field separator in the files? What if a text value contains an asterisk within it?
The use of the asterisk (*) as the field separator is both a HIPAA and state regulation specification and must be used to separate each field within the required files.

Although not specifically stated in the rule, it is perfectly valid to enclose any or all text/alpha fields within double quotes (e.g., "abc"). If a required text value actually contains an (*) as one of its characters, then that field must have double quotes around the entire value (e.g., "ab*cd").

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. Double quotes most commonly appear in the pharmacy claims field PC027 (Drug Name).

Is it permissible to use special characters in ME032 (Group Name)?
If the special character is an asterisk (*), then the group name should be in double quotes. All other special characters are allowable in ME032 with no double quotes.

We have a Medicare supplemental product that covers only the member responsibility for Medicare covered services. Are we supposed to report data for those members?
Yes. Medical eligibility and claims data should be reported for members who have only supplemental coverage. If the policy also pays for non-covered Medicare services, the eligibility and claims data are to be submitted.

What are the steps for submitting and processing files?

1. After creating data extracts as specified by the NH Administrative Rule on Claims Data Collection, run each file through the NHpreprocessor application. This application will be emailed to all who have completed and submitted the NH CHIS registration form.
   The NHpreprocessor hashes the patient identifier data elements, performs some basic file validation, generates a unique file name based on data in the header record, and compresses the file for transfer.
2. Send all files to Milliman via your Secure FTP account, (if you need an SFTP account, please email: NHCHISsupport@milliman.com.)
3. Milliman processes the files. An overview of each stage of the process is as follows:

Pre-upload validation

• The file is unzipped.
• File is checked for the correct number of fields in header, trailer, and data lines.
• File is checked to make sure it's been run through the hashing application. If file cannot be uploaded, responsible data submitter(s) are notified via email.

Data Upload Data is loaded into preliminary upload tables in a SQL Server database, and each file is assigned a unique File ID.
Data file validations are run on each uploaded table, and the established data submitter(s) will receive an email notifying them of the status of their data (PASS/FAIL) and results of the following types of data validations that were run:

• Frequency of data exceeding required length of field
• Frequency of invalid data format.
• Frequency of field population - this is shown as a minimum length check.
• Frequency of invalid values within field.

Data Quality Checks Over 130 data quality checks are performed on the data. A sample of these checks include:

• Percentages of claims unsupported by eligibility
• Review provider data issues
• Identification of duplicate claims
• Trend Statistics from prior month
• Distribution of age based on date of birth

Definitions of file status notifications

1. CATASTROPHIC FAILURE: The file failed with incorrect number of fields in the record or the field size was greater than the maximum length or the field size wasn’t the required format. The file will need to be corrected and resubmitted. You cannot request an exception for a catastrophic failure.
2. FAILED: The file threshold requirements were not met. Either the data would need to be corrected or an exception request can be submitted.
3. PASSED: The file contained no errors.

Transformations

• If data has passed all prior steps, the data move into a stage where value-added fields are generated (e.g., Health Care Cost Groupers, etc).
• This stage results in a status declaration of either DONE or ERROR.
• An ERROR status indicates either a processing error (program error) or an unexpected data error.
• If the file results in an error, the responsible data submitter(s) are notified by email.

Hashing

Which data is being hashed and how will it get hashed?
All member-identifiable specific data elements will be hashed the NHPreprocessor application. The software program will hash the following fields in the eligibility and claims data:

Member Eligibility

• ME008 Subscriber Unique Identification Number (subscriber's SSN)
• ME009 Plan-Specific Contract Number
• ME010 Member Suffix or Sequence Number
• ME011 Member Identification Code (member's SSN)
• ME101 Subscriber Last Name
• ME102 Subscriber First Name
• ME103 Subscriber Middle Initial
• ME104 Member Last Name
• ME105 Member First Name
• ME106 Member Middle Initial

Dental Claims

• DC007 Subscriber Unique Identification Number (subscriber's SSN)
• DC008 Plan-Specific Contract Number
• DC009 Member Suffix or Sequence Number
• DC010 Member Identification Code (member's SSN)
• DC101 Subscriber Last Name
• DC102 Subscriber First Name
• DC103 Subscriber Middle Initial
• DC104 Member Last Name
• DC105 Member First Name
• DC106 Member Middle Initial

Medical Claims

• MC007 Subscriber Unique Identification Number (subscriber's SSN)
• MC008 Plan-Specific Contract Number
• MC009 Member Suffix or Sequence Number
• MC010 Member Identification Code (member's SSN)
• MC101 Subscriber Last Name
• MC102 Subscriber First Name
• MC103 Subscriber Middle Initial
• MC104 Member Last Name
• MC105 Member First Name
• MC106 Member Middle Initial

Pharmacy Claims

• PC007 Subscriber Unique Identification Number (subscriber's SSN)
• PC008 Plan-Specific Contract Number
• PC009 Member Suffix or Sequence Number
• PC010 Member Identification Code (member's SSN)
• PC101 Subscriber Last Name
• PC102 Subscriber First Name
• PC103 Subscriber Middle Initial
• PC104 Member Last Name
• PC105 Member First Name
• PC106 Member Middle Initial

Note that you must not encrypt these fields before passing them through the NHpreprocessor. If you do not pass the actual Social Security numbers or plan-specific contract numbers through the hashing application, you will be required to resubmit the data. After these fields are hashed, NHpreprocessor software will compress, password-protect, and rename the file for transmission.

There is something wrong with the hashing software. I can't get it to work. What should I do?

1. Check your data for embedded asterisks in the data values. These must be enclosed in double quotes.

If these steps do not correct the problem, email NHCHISSupport@Milliman.com.

We padded the three fields to be hashed with spaces/blanks to the right of the value to the field's maximum length. Is this acceptable?
No, this is not acceptable. The hashing 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 hashed as part of the member's SSN or plan-specific 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 hashed values will not match. Padding the SSN or the contract number will require data resubmission.

We stripped off the leading zeroes from the SSN before running it through the hashing 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 hashed values will not match. Removing leading zeroes from the SSN will require data resubmission.

Transmission

If I am using the web upload process, how can I be sure the transmission is both secure and complete?
The NHpreprocessor includes a built-in compression routine that password-protects the files and makes them more manageable for online transmission. The web upload process runs on a secure server that includes a security certificate declaring its operation by Milliman. When an upload process is complete, a confirmation screen is displayed for the payer; additionally, the payer's specified contact person for the specific file type will receive a confirmation email from Milliman.

How do I determine if my web transmission is safe?
There are two things that you can do to make the transfer as secure as possible:

1. First, use the SSL/TLS certificate to ensure that the website you are connecting to is, in fact, the website that you are supposed to be connecting to. When logging in to the Milliman MedInsight Secure Transfer Server you should see an icon of a locked golden padlock along the bottom of your browser window. By clicking on this icon, the security certificate can be viewed and examined. If you believe the certificate is invalid or if the padlock icon is unlocked, contact us before proceeding.
2. Second, use the highest supported level of hashing when transmitting data to us. There are several levels of hashing that are supported by the SSL/TLS standard (including 50-bit and 128-bit). Our web server supports higher level 128-bit hashing, which is significantly more difficult to crack. If you are concerned about security, you should make sure that the browser you're using supports 128-bit hashing.

Whom do I contact if I am having upload problems?
For general transmission questions or for web upload questions, please email NHCHISSupport@Milliman.com.

What is the transmission time frame for the data?
According to the rule, monthly submitters must file the data by the last day of the month for the previous month's activity. For example, data for September must be submitted by October 31.

Data

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 nonspecific codes.

What if our system uses "homegrown" or locally defined claim processing/CPT codes to pay certain types of claims? What do you want us to do if these codes are longer than the five digits that are defined in the file layout?
Following HIPAA standards, all homegrown/local processing codes should be eliminated from your systems. Milliman is using standard lists that are refreshed monthly and will no longer load homegrown codes.

What if we have a data value that is longer than the maximum length specified in the rule?
Typically, Milliman cannot accommodate increasing the maximum length for any field. However, if a carrier has a data value that is longer than the maximum length, you will need to send Milliman an email at NHCHISSupport@Milliman.com indicating the file type, the data element number, the data element name, the maximum length specified in the rule, and the maximum length you are requesting to submit. Milliman will send your request to DHHS for their evaluation, as your modification would also apply for all suppliers.

What if some of the data being requested is not available to us to send to you?
In general, all data elements that can have an appropriate blank/null value have been identified in the layouts for the individual files. However, we understand that there are limitations within different processing and data warehouse structures. According to the data collection rule, any required data elements that you receive must be submitted. You must notify us annually of any data elements that you are unable to supply. We will discuss the situation with you and, pending approval by New Hampshire State officials, make any necessary accommodations. Such accommodations will be in place for only one year and must be renewed annually.

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 dispensed pharmaceutical. It should contain at least the ingredient cost / list price, the billed amount (usual and customary charge), the dispensing fee, any administrative fee, and any applicable tax.

Are we to include the procedure code as it was submitted or as it was paid?
If you have the ability to recode CPTs based on claims processing and standard CPT coding logic, then the CPT that should be included in the file is the CPT tied to the actual payment dollar amount.

For example, the relevant elements in the medical claims file include:

• MC055 (CPT Procedure Code) - CPT code of procedure as paid
• MC062 (Charge Amount) - Dollar amount of submitted procedure (billed charges)
• MC063 (Paid Amount) - Dollar amount of paid procedure

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

The member DOB is not always known/tracked in our system at the time of enrollment, is it acceptable to leave 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.

The coverage level code of a member could change during the middle of a month. Which status code do you want us to submit -- the first, the last, or all of them in a given month?
The status code for the Coverage Level field (ME007) in the eligibility file should be either the status as of the end of the month or the applicable code for when the premiums were billed for that member during the month.

Why did my file fail with an "invalid relationship code" error?
One of the frequent problems that we have found with many payers is the coding of individual relationship code fields (ME012, DC011, MC011, PC011). These code values are different between file types for the same member because of HIPAA coding specifications that were followed. Please pay close attention to any of the coded fields.

Why did my file fail with an "invalid product code" error?
Product sometimes is misinterpreted as the type of business that you, as the payer, see yourself doing. Actually, the value in the PRODUCT fields (ME003, DC003, MC003, PC003) should reflect the type of product that a subscriber/member is covered under instead of the type of insurance company the payer considers itself to be. Many payers have used the code of CI (Commercial) for every member to say that they are a commercial insurer, yet the members were covered by products that most properly would be considered a POS product, a PPO product, or an Indemnity Insurance product. (Note that the eligibility and claims files often use different codes values for the same value. For example, a POS product would be coded PS in the eligibility file but 13 in the claims files.)

Data Definition

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.

What is meant by the Plan-Specific Contract Number and how is it different from the Subscriber SSN?
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.

What is the National Pharmacy ID Number (PC021)?
This field represents the proposed HIPAA unique identifier for pharmacies nationally -- much the same as the proposed unique provider number or the unique member/patient number. This value has a future HIPAA implementation date and currently should have no value in the file.

We bundle our approved claims on a weekly basis and cut/send one combined check to the provider each week or month. What date do you want to see in the Date Service Approved fields (DC017, MC017, PC017) -- the date the claim was approved for payment or the actual check paid/cut date?
What should be listed in the Date Service Approved fields is the date on which the claim was approved for payment. In most processing systems, this is known as the AP (Accounts Payable) Date.

We have an "Employee +1" premium rate that can be used to cover both a subscriber and spouse or a subscriber and dependent/child. Which value should we use -- ECH, ESP, or FAM -- in the coverage level code (ME007) in the eligibility file?
If you cannot distinguish between two adults or one adult plus a child, then the "Employee +1" rate should be coded as FAM. If, after reviewing the definitions, you would like assistance in clarifying which codes should be mapped to your system-specific values, please email us. .

We carry only one field in our data warehouse that contains the entire provider name. We cannot break the field apart into first name, last name, middle name/initial, etc. Which field should we use to send this to you?
When the provider name absolutely 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 be done only as a last resort.

Should text fields be padded with blanks and should numeric fields be padded with zeroes 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 zeroes, 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.

Top of Page

Data Submission Requirement Clarification

Can you clarify the requirements related to which entities must submit data to NH CHIS?
New Hampshire's collection rule was updated, in June 2015, to provide further clarifications on required submissions to NH CHIS. A summary follows:

The INS4000 rule changed the requirements for submissions, effective 1/1/2016. If your corporate entity (please confirm with parent company if applicable) does not cover more than 9,999 lives in medical, pharmacy or dental coverage classes, and you do not offer any products on the health insurance exchange for residents of NH, then you are not required to submit data. Please continue to submit data for claims incurred to complete the run out process as described in Part4005.01 (d).

Please note: If a corporate entity has many subsidiaries, NH will require data submission on covered lives in NH from each entity if the numbers of lives aggregated at the governance level exceeds 9,999 lives.

Regardless of payer type (carrier or TPA) the requirement for reporting data for both self-insured and fully insured businesses is as follows:

• All insurers covering New Hampshire residents must submit claims data for those residents to NH CHIS, regardless of whether the policy was written in New Hampshire or out of state.
• All policies written inside New Hampshire, regardless of whether they cover in-state or out-of-state residents, must supply that claims data to NH CHIS.

In the latter case, the policyholder is considered to be the employer/business or individual that contracts directly with the payer to obtain health coverage services. Under this definition the following examples provide scenarios in which claims data would or would not be required in a data submission.

Scenario 1: A local, non-national NH business contracts with a payer for health benefits, but has a few employees living in the border states of Maine and Massachusetts. All of this business's data must be submitted, even for the members living in Maine or Massachusetts.

Scenario 2: A national business's headquarters are located in New Hampshire and it uses that office to contract health benefits/policies for all of its employees nationwide. Again, all of this business's data must be submitted, even for members living in other states.

Scenario 3: A payer offers individual health benefits to New Hampshire residents, their families, and/or small businesses directly. All of the data for these individuals and members covered under the policy must be submitted.

Scenario 4: A company/business with its headquarters located in another state has chain stores, operations, and/or employees in New Hampshire, but issues health care benefits/policies from a location outside of New Hampshire. This data must be submitted for all of the covered lives, including those with New Hampshire residency.

Scenario 5: As in Scenario 4 above, a company/business has its headquarters located in another state. However, the local New Hampshire chain store or operations contracts for the health benefits provided to the employees located in New Hampshire and/or other states. All covered lives under such a policyholder must be submitted.

The above definitions and scenarios apply to both fully funded businesses and self-funded businesses. If you are a payer and have a situation with a policyholder that does not align with these scenarios and needs further guidance, please email Maureen.Mustard@ins.nh.gov and we will determine if the data is required or exempt.