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:
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:
- 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.
- 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
- 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).
- 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).
- 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
- 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.
- 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.
- Invalid diagnosis codes. Payers must report all valid characters
of the ICD-9 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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
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?
No. Medical eligibility and claims data are not to be reported for members who have
only supplemental coverage. However, 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?
- 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.
- Send all files to Milliman via your Secure FTP account, (if you need an SFTP account, please email: NHCHISsupport@milliman.com.)
- Milliman processes the files. An overview of each stage of the process is as follows:
- 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 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:
This stage results in a status declaration PASSED or FAILED or CATASTROPHIC FAILURE.
- 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
Date submitter(s) are notified by email, of the status of their processed file.
- 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.
- FAILED: The file threshold requirements were not met. Either the data would need to be corrected or an exception request can be submitted.
- PASSED: The file contained no errors.
- 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.
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:
- ME008 Subscriber Unique Identification Number (subscriber's SSN)
- ME009 Plan-Specific Contract 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
- DC007 Subscriber Unique Identification Number (subscriber's SSN)
- DC008 Plan-Specific Contract 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
- MC007 Subscriber Unique Identification Number (subscriber's SSN)
- MC008 Plan-Specific Contract 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
- PC007 Subscriber Unique Identification Number (subscriber's SSN)
- PC008 Plan-Specific Contract 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?
- Download the sample data files from Milliman's secure portal and run those through the hashing software.
- Check your data for embedded asterisks in the data values. These must be enclosed in double quotes. /li>
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:
- 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.
- 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.
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:
- 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.
- 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?
Top of Page
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.
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?
Top of Page
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.)
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 has been updated, most recently in June 2015, to provide
further clarifications on required submissions to NH CHIS. A summary follows:
The new INS4000 rule has changed the requirements for submissions, starting 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 no longer required to submit new data in the coming year. 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 has been expanded 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
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 us and we
will determine if the data is required or exempt.
Top of Page