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.
[ close ]

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.)
[ close ]

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.
[ close ]

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.
[ close ]

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.
[ close ]

If this is the case for your processing system, Onpoint will accept the total value in one of the fields. Of the three data elements, Copay Amount  is the most useful. Therefore, we would like to have at least Copay Amount  pulled out of the member total and reported in the appropriate element (DC039, PC040, MC065). The other two values -- Coinsurance Amount and Deductible Amount -- can be left as a total and reported in either the Coinsurance Amount or the Deductible Amount data element. If this situation exists in your system, please tell us how you will be loading the data into these elements before transmitting any files to us.
[ close ]

Onpoint CDM's encryption software package 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 Onpoint Health Data and Onpoint CDM. 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 Onpoint CDM.
[ close ]

The encryption application is a web-based application written by Onpoint Health Data that can be downloaded to a desktop from the Onpoint CDM website. 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 identified easily during the uploading of the file to Onpoint CDM

 
[ close ]

Any of the following can cause the submission to be rejected:

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

b) 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).

c) 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).

d) 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.

e) Invalid and missing procedure codes. If a payer accepts local CPT codes and does not provide those codes and their associated descriptions to Onpoint, 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.

f) 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.

g) 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.

h) 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.

i) 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.

j) 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.

k) 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.

l) Invalid file format. 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. For example, while the Maine and New Hampshire data sets are very similar, the number of fields in their medical and eligibility files differ. (New Hampshire has one less eligibility field and one more medical claims field than Maine.) If Maine-formatted data is run through New Hampshire's encryption application, the encryption will fail. Similarly if New Hampshire-formatted data is run through the Maine encryption application, the encryption will fail.
[ close ]

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 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.
[ close ]

Yes there is; however, we want to limit these types of submissions to a minimum as it complicates transferring data to the state. Basically, if a carrier identifies a block of data that should have been included in a monthly paid data submission that already has been accepted but for one reason or another was omitted, then we 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; we have a process in place that, once this special data submission has been accepted, ensures the data will be migrated to the proper submitter code. If a carrier's original submitted file has yet to be accepted, then the carrier will be asked to resubmit both the data from the original data submission and any new data identified in one file.
[ close ]

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.
[ close ]

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 required historical data feeds, carriers must submit one record per member per month of active coverage for the defined historical period. For the historical data, we require that each month of eligibility data be submitted in a separate monthly file.
[ close ]

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 of 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.
[ close ]

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.
[ close ]

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 cannot be submitted must be approved by the appropriate state officials before the submission can be accepted.
[ close ]

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.
[ close ]

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.
[ close ]

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 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 encrypted values will not match. Padding the SSN or the contract number will require data resubmission.
[ close ]

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 data resubmission.
[ close ]

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.
[ close ]

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.
[ close ]

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. Onpoint Health Data also requires a spreadsheet that contains any homegrown 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.
[ close ]

Depending upon the load completeness requirements for the state for which you are reporting data, this may cause your submission to fail.
[ close ]

The denied code option is listed for two reasons:

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

2. If a previously 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.
[ close ]

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, the dispensing fee, any administrative fee, and any applicable tax.
[ close ]

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 secure portion of Onpoint CDM (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 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 encryption when transmitting data to us. There are several levels of encryption that are supported by the SSL/TLS standard (including 50-bit and 128-bit). Our web server supports higher level 128-bit encryption, 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 encryption.
[ close ]

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").
[ close ]

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

All registered contacts for a payer will receive emails from Onpoint CDM 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 by logging on to the system and looking at the entries associated with that submission.

Emails also may be sent by Onpoint CDM's data manager and data intake specialists 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 Onpoint and the payer.
[ close ]

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

No, workers' compensation claims are not reported.
[ close ]

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 also may 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.
[ close ]

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 at the individual person level.
[ close ]

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 percent paid by the carrier in January. In March, though, the claim is "backed out" (a negative offset claim is created) and a new claim is created to split the payment of the service to 80 percent carrier liability and 20 percent 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 as well as the new payment claims with the paid dollars reported appropriately for the carrier and member fields.
[ close ]