|
||||||||||||
Frequently Asked Questions
GeneralWhy do we have to submit this data? To be in compliance with New Hampshire Chapter Ins 4000, The Uniform Reporting System for Health Care Claims (http://gencourt.state.nh.us/rules/ins4000.html). The Maine Health Information Center (MHIC) is an agent for the State of New Hampshire and is authorized to receive this data. How will I find out if my submission failed? All registered contacts for a payer 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 by logging on to the system and looking at the system entries associated with that submission. Emails may also be sent by the Data Manager to the contacts for data quality issues. These emails are customized and contain specific information about the problems identified. An email initiated by the Data Manager often results in opening a dialogue between the payer and the Data Manager. What are the most common mistakes made when submitting data? Any of these can cause the submission to be rejected.
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 both a HIPAA and a State of New Hampshire 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 - 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". 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 field PC027 – Drug Name. 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. When a file is submitted to you what are the steps to process the file? Outside of the Web Upload Process: The file is run through the encryption software that encrypts the patient identifier data elements, performs some basic file validation step, generates a unique file name based on data in the header record, compresses and password protects the file for transfer. The Data Checking Process
Top of Page EncryptionWhat data is being encrypted and how will it get encrypted? The member identifiable specific data fields/elements will be encrypted by an encryption software package that will be available to you via the web on August 17, 2005. The software program will encrypt the Subscriber and Member SSNs and the Subscriber Contract Number. Only these three fields will be encrypted. Additionally, software will compress, password protect and rename the file. You must not encrypt these fields before passing them through the encryption software. If you do not pass the actual SSN’s or Subscriber Contract Number through the encryption application, you will be required to re-submit the data. There is something wrong with the encryption software. I can’t get it to work. What should I do?
If the above do not correct the problem, email us at nhdata@ncdms.org. We padded the three fields to be encrypted with spaces/blanks to the right of the value to the field’s maximum length. Is this OK to do? No, this is not valid. The encryption software will do one of two things:
We stripped off the leading zeroes from the SSN before running it through the encryption software. Is this OK to do? No, this is not valid. 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. Top of PageTransmissionIf I am using the Web Upload process, how am I sure the transmission is safe and complete? As part of the encryption software package that you will be using, we have built in a compression routine to make the files more manageable for transmission over the web. This routine will also password protect the files. The Web Upload process runs on a Certified secure server. "Certified" means that the Web Upload process is guaranteed to belong to the Maine Health Information Center. "Secure" means that data is encrypted during its transmission from your computer to the server. When an Upload process is complete you will see a completion screen. Also the contact person for the specific file type will receive a confirmation email. How do I determine if my web transmission is safe? If you are interested in using the Web file transfer, there are two things that you can/should do to make the transfer as secure as possible:
Whom do I contact if I am having Upload problems? For general transmission questions or for Web Upload questions please contact nhwebadmin@ncdms.org 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. Therefore, on October 31, 2005, data for September 2005 must be submitted. The initial submission will be January 1, 2005 through August 31, 2005 by October 1, 2005. Top of PageDataThe different file layouts have different coding schemas, Why? We have attempted to use the HIPAA standard coding schema in all cases and the HIPAA electronic transmission coding standards are not standard across the different file types. What if our system uses "Home Grown" or local claim processing/CPT codes to pay certain types of claims? What do you want us to do if these codes are longer than the 5 digits that are defined in the file layout? Following HIPAA standards, eventually all "Home Grown"/local processing codes should be eliminated from your systems. Until that point in time we will accept local CPT codes. You must submit an Excel spreadsheet with all local codes and their descriptions to nhinfo@ncdms.org before submitting your medical claims data or your submission may fail. What if we have a data value that is longer than the maximum length specified in the rule? Send an email to nhinfo@ncdms.org indicate the file type, the data element number, the data element name, the maximum length specified in the rule, and the maximum length you need to submit. We will follow up with instructions as to whether the field should be truncated or if we can accommodate the longer length. If you submit data with a data element length greater than specified in the rule, your submission may fail. 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 you receive must be submitted. You may notify us annually of any data elements you are unable to supply. We will discuss the situation with you and, pending approval by NH State officials, make the necessary accommodations. The accommodations will be in place for 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 do we do? The amount/value of this data element should represent the fully loaded cost/charge of the drug. It should contain at least the Ingredient Cost/Billed Amount, the Dispensing Fee, any Admin Fee and any applicable Tax. In the file layouts you break out the Member Liability costs into Copay, Coinsurance and Deductible data elements. Our system stores them all in one field as a total member liability. How should we report this? If this is the case for your processing systems, then we would accept the total value in one of the fields. Of the three data elements, the Copay amount is the most useful. Therefore, we would like to have at least that value pulled out of the member total and reported in the appropriate element (MC065). The other two values can be left as a total and reported in either the Coinsurance (MC066) or Deductible (MC067) data element. Be careful In any case, if this situation exists in your systems please tell use how you are going to be loading the data into these data elements before transmitting any files to us. Are we to include the procedure code 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 that should be included in the file is the CPT tied to the actual payment dollar amount. Medical Claims file example:
MC055 - CPT Code of procedure as paid In this example the CPT codes for the dollar amounts listed in DC037 and DC038 could be different and 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? This will hit one of our many eligibility edits. If more than 50% of the dates in your submission are blank, then the submission will be automatically rejected. The coverage level code of a member could change during the middle of a month, what status 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. Why did my file fail with an "invalid relationship code" error? One of the frequent problems that we found in many payers was with the coding of individual relationship code fields (ME012, 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 is sometimes misinterpreted as the type of business you, as the payer, see yourself doing. Actually, the value in the product field (ME003,MC003,PC003) should reflect the type of product that a subscriber/member is covered under instead of what type of insurance company the payer considers itself. There were many payers using the code of CI - Commercial for every member to say that they are a commercial insurer, yet the members were covered by products that would be considered a POS product ('PS' in the eligibility file or '13' in the medical, dental, or prescription claims files) or PPO product ('PR' in the eligibility file or '12' in the medical, dental, or prescription claims files) or IND product ('IN' in the eligibility file or '15' in the medical, dental, or prescription claims files). In an attempt to clarify this situation and avoid confusion over what we are looking for in this field, Rule 243 was modified and some commonly misused products codes were eliminated. An Email was sent out to all contacts with highlights of the changes and a copy of the full Rule attached in Early June. If you do not have a copy of the updated Rule please go to our Web Site: www.ncdms.org and from the main page download the June 3rd revised Rule. Top of PageData DefinitionWhat is meant by the Insured Group or Policy Number? The Insured Group and/or Policy Number is the Employer Group or Account number for the Contracted Employer. There may be one or more of these numbers for a given employer group according to how your system is setup. Also, if your plan writes individual policies, this number would be the actual policy number and not the subscriber's identification/contract number unless your system uses the same number for these two elements.
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. The Plan Specific Contract Number is an Insurer defined Subscriber level unique identifier. In many cases the subscriber's SSN may be used as the Contract Number. This is the Member level data, along with the Member SSN element, that will be encrypted. What is the National Pharmacy ID Number? 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. The Claim Status field in the file layouts contains a code of "04 Denied"; however, the rule states 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 why the 04 code option is listed? The denied code option is listed for two reasons:
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 (MC017, PC017) (ie. 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 known as the AP (Accounts Payable) Date. We have an "Employee +1" premium rate that can be used to cover both a subscriber & spouse or a subscriber & dependant/child. What value should we use, ECH, ESP or FAM in the coverage level code in the eligibility file? If you can not 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 what codes should be mapped to your system specific values please contact nhinfo@ncdms.org. We only carry one field in our data warehouse that contains the entire provider name. We cannot break the field apart into first, last, middle initial etc, what field should we use to send this to you? When the provider name CANNOT be separated into first, last, middle & suffix elements than the entire provider name should appear in the "Service Provider Last Name or Organization Name" field. Should text fields be padded with blanks and numeric fields be padded with zeros to their maximum length? No, the record layouts, although showing an acceptable maximum length, were designed to be variable length. No text field should be blank or space padded on either the right or left. 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 is compressed, there is still space used to represent the blanks, spaces and zeroes. In a large data file this additional space could be substantial enough to lengthen the transfer time. Also, if the three 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. Please refer to the Encryption section of this page for specifics. NHCHIS DATA SUBMISSION REQUIREMENT CLARIFICATION: as of Aug. 25th, 2005 The Rule Clarification and examples below are preliminary and are subject to change after final review by the State of NH Insurance Department. 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 payer (defined as Carrier and TPA) that does not meet the requirements for submission exclusion as defined in the New Hampshire Rule - Chapter Ins 4000 by premium level or membership level is required to submit data to the contracted entity. The requirement for exclusion for Carrier's is less than $250,000 in accident and health insurance premiums in New Hampshire on an annual basis and for TPA's is administrators of health insurance plans covering fewer than 200 New Hampshire lives in total. Regardless of payer type (Carrier or TPA) the requirement for reporting data for both self-insured and fully insured business is based on the location of the policyholder. If the policyholder is a New Hampshire business or resident then the claims data must be reported for all persons covered under that policy, regardless of the residency of those persons. In this case 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 lists situations where the data would or would not be required in a data submission. Example 1: A local non-National NH business contracts with a payer for Health benefits, but does have a few employees living in border states of ME and MA. All of this businesses data is required to be submitted, even for the members living in ME or MA. Example 2: A National business headquarters is located in NH and contracts Health benefits/policies for all of its employees nationwide through the main office in NH. Again, all of this businesses data is required to be submitted, even for members living in CA, TX, AZ, etc. However; if sending in all of the data for these members is problematic for a payer based on multiple processing systems/locations, etc there may be exceptions to this requirement, please contact the us at nhinfo@ncdms.org with your concerns. Example 3: A payer offers individual Health benefits to residents of NH and their families and/or small businesses directly. All of the data for this individual and covered members under the policy is required to be submitted. Example 4: A company/business with its headquarters located in another state, ie. ME, AK, etc, has chain stores/operations/employees in NH, but issues Health Care benefits/policies out of a location outside of NH. Under the current rule structure this data is NOT required to be submitted for any of the covered lives including those with residency in NH. Example 5: Same as in example 4 a company/business has its headquarters located in another state; however, the particular chain store or operations located in NH contracts for the health benefits for the employees located in NH and/or other states. Any covered lives under such a policyholder are required to be submitted under the rule. Example 6: A Labor Union, Employer Association or Coalition offers Health Benefits to its members and the associations headquarters is not located in NH, thus the policy is issued outside of NH. Then the data for these policies would not be required to be submitted. However, If the association was located in NH and the policy was issued in NH all members data would be required to be submitted regardless of the members State of Residents, even if an out of State Health Benefits Broker was employed by the association. The above definition and examples are the same for both fully funded business and self-funded business at a payer. If you as a payer have a scenario with a policyholder that does not fit within one of the six examples above please contact us at: nhinfo@ncdms.org and we will 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. Top of Page |
||||||||||||
|