Frequently Asked Questions

      Do we have to use the asterisk (*) as the field separator in the files? What it a text value contains an (*) within it?

The use of the asterisk (*) as the field separator is a HIPPA and Maine Health Data Organization Rule 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 enclosed 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".

      Are claims filed for vision coverages considered a reportable health care claim for purposes of this Act?

Yes, vision coverage is included under Chapter 243 and should be submitted in the claims layout. This would include visits to an Optician or Ophthalmologist for routine eye exams, surgeries, etc. but would not include claims for eye glasses and/or other corrective products services.

      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 which

   Encrypts the necessary data elements

   Performs some basic file validation steps

   Generates a unique file name based on data in the header record

   Compresses and password protects the file for transfer.

The Data Checking Process

Stage	Process
Transmit	The file has been received via the Web upload or from physical media.
Prelim	The file is unzipped. If this is a resubmission of a file, the submission number is incremented. Information in the file header is compared to information given by the sender on the upload screen. File is checked for the correct number of fields in header, trailer, and data lines. File checked for presence of 3 encrypted fields. File checked for decimals in payment fields or in diagnosis fields. This stage results in either PASS or FAIL status.
Load/Compliance	The file is loaded into ORACLE holding tables. Any loading errors will cause this step to fail. Likely causes of load failure include a data value too large for the defined database table element and an invalid value for the field definition type (eg, a character where a number is expected). If the actual load to the table is successful, then other validation processes take place. Most of these validations deal with determining the frequency of certain required data elements. This stage results in either PASS or FAIL status.
Transformations	The data now moves into a stage where value added fields are generated: Hedis Age Cohorts, Diagnosis categories, CPT categories, HSA10 codes, etc. This stage results in status DONE or ERROR. An ERROR status indicates either a processing error (program error) or an unexpected data error.
Data Quality Checks ("Edits")	Over 600 data quality checks are performed on the data. These checks include percentages of claims unsupported by eligibility, trending percents from prior month, percentages of unknown and/or home grown CPT and DX codes, percentage of valid Insurance Type codes, Maine Zip codes; distribution of age based on DOB, etc. This stage results in statuses ERROR, DONE, PASS, FAIL. An ERROR status indicates either a processing error (program error) or an unexpected data error. If a processing error occurs, the code is adjusted and the file is reprocessed. A status of DONE means that all the data quality counts and percentages have been completed and the resulting report awaits visual review. After manual review of the data quality report, the file's status will be set to PASS or FAIL. At this point, a brief report will be emailed to the submitter, indicating the status of the submitted file and including a link to the website for a complete report. If the file PASSES the manual validation step then the data is loaded into the monthly production database structure.

Encryption

      What 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 on November 1, 2002. The software program will encrypt the Subscriber and Member SSNs and/or the Subscriber Contract Number. Only these three fields will be encrypted. Additionally, software will compress, password protect and rename the file.

      We padded the three fields to be encrypted with spaces/blanks to the right of the value to the fields maximum length. Is this OK to do?

No, this is not valid. 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 members SSN or contract number. This causes problems when trying to find unique members across the state if one insurer submits the data with padded blanks/spaces and then the member changes to a new insurer that does not pad the field with blanks/spaces the members encrypted values will not match.

Transmission

      If 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 Data 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.

For general transmission questions or for Web Upload questions please contact webadmin@mhdpc.org

According to the rule, the data must be filed by the last day of the month for the previous months's activity. Therefore, on January 31, 2003, data for December 2002 must be submitted.

There was a limited amount of time to implement a solution that would work as well as possible for hundreds of data submitters and that would do so with a reasonable level of security. Most data submitters will have access to a Windows work station that would be capable of running the encryption utility and an SSL-enabled Web browser capable of doing the secure Web file transfer.

It is possible to allow a Windows executable like the encryption utility to accept parameters (file name, file type, etc) from the command line which would allow it to be included in a script or batch file and automated. The current version of the encryption utility does not do this, but if there is a demand for it we would certainly look at adding this feature to future versions. For data submitters that do not have access to a Windows work station or cannot live with the limitations of the utility that is being provided, the encryption algorithm that is being used is available and the details like file compression method and file-naming conventions could be worked out. The existing encryption utility could still be used to begin the test process with the formatted text files and as a reference to compare against while developing an alternative.

Other methods of secure file transfer (SCP, SFTP, Kerberized FTP) that might be more script/batch friendly were looked at, but none seemed to be as simple to implement and universally accessible as SSL Web file transfer. We do not at this time provide any means of scripting the Web transfer but, as testing progresses, we will have a chance to look at this possibility.

     The Jan 2003 Newsletter mentions two ways to determine if our transmission is as safe as possible. What are the details?

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:

1. Use the SSL certificate to help you to insure that the Web site you are connecting to is, in fact, the Web site that you are supposed to be connecting to. When connecting to the secure portion of the MHDPC web site (user services including encryption utility software download, data file upload, and data submission reports), you should see an icon of a locked golden padlock along the bottom of your browser window. By clicking on this icon, the certificate can be seen. You should examine the certificate and make sure that the certified network address, organization name, and organization location are what they should be (secure.mhic.org, Maine Health Information Center Inc, Manchester, Maine, US) and that the certificate date range is valid. If this information is not valid, or if you see the icon of an unlocked golden padlock along the bottom of your browser window, you should contact us before proceeding.

2. Use the highest supported level of encryption. There are two levels of encryption that are supported by the SSL standard (50-bit and 128-bit). Some Web browsers support only the lower level of encryption (50-bit). Our Web server supports higher level 128-bit encryption but will negotiate with the Web browser that is asking for a connection and will drop down to the lower level 50-bit encryption if that is all that your browser can support. The 128-bit encryption is significantly harder to crack than the 50-bit and if you are submitting data that you want to be especially secure, you should make sure that the browser you are using supports 128-bit encryption. You can check this by clicking on the help option in Internet Explorer and going to the "about Internet Explorer" drop-down menu option. On the popup screen, there will be an entry titled "cipher strength" which will say either 50-bit or 128-bit. If your browser is using 50-bit encryption, you can download the 128-bit version of Internet Explorer for free from Microsoft.

Data

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

If you cover an Employer group in the State and they opt out of any Pharmacy coverage rider, but you still have to provide benefits for items like Diabetic Supplies or certain Injectable Products, then, even though this data would come to us in the Pharmacy file transmission you would load a ""NO"" value for the member(s) in this employer group.

Following HIPAA standards, eventually all "Home Grown" processing codes should be eliminated from your systems. Until that point in time we suggest that you do the following: Since the file format that you will be sending to us is a delimited ASCII file you can send us the full length value of this field in the correct data element. As part of our validation check we will verify the longest length value in this element and make sure that the Data Warehouse can accommodate the whole value. We would also ask that you send to us, in electronic format, all "Home Grown" code values and an english definition for each.

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

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 Amt, the Dispensing Fee, any Admin Fee and any applicable Tax.

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 data is the most useful and we would like to have at least that value pulled out of the total and reported in the appropriate element, then the other two values can be left as a total and reported in either the Coinsurance or Deductible data element. 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.

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.
Dental file example:
     DC032 - CPT Code of procedure as paid
     DC037 - $ amount of submitted procedure (billed charges)
     DC038 - $ amount of paid procedure

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

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

One of the frequent problems that we found in many payers was with the coding of individual relationship code fields (ME012, MC011,PC011,DC011). 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.

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,DC003,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.mhdpc.org and from the main page download the June 3rd revised Rule.

There is a provision in the rule to have all payers submit to us a spreadsheet of all provider specialty codes that are included or could show up in any of the claims files. If you have not done so please submit this information to us via Email, CD or Floppy. The spreadsheet should contain the provider specialty code and a definition of the code. We would also appreciate it you could send to us, again if you have not done so already, a spreadsheet that contains any Homegrown or Local Procedure, Revenue and Diagnosis codes. If you use Homegrown codes these files are critical for any research organization to be able to group like procedures or diagnoses together. We appreciate your cooperation in collecting this data.

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

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.

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 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 previous submitted paid claim was later reprocessed and some or all or the claim lines were denied then we would need to see that claim appropriately coded so that the original paid dollars will be balanced out of the database tables.

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.

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 you have questions regarding the definition of these codes, they were pulled from the X12 Directories section in Appendix A of Rule 90-590 Chapter 243. If after reviewing the definitions you would like assistance in clarifing what codes should be mapped to your system specific values please contact info@mhdpc.org.

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.

We no that this issue exists and right now we would want to see those claims rather than put the burden of eliminating those claims from the file on you. They will result in claims records with no supporting eligibility records in our database for Jan 03. We will have to evaluate these records on an ongoing basis and determine if they should be dropped from the database. We feel this is the best current solution rather than ask you, the submitter, to try and determine if and when the address of a subscriber changed from one state to another.

No, the record layouts, although they list a maximum length that we will except, were 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 is compressed there is still space used to represent the blanks, spaces and zeros and in a large data file this additional space could be substantial enough to lengthen the transfer time.

Also, if the 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.

Maine Health Data Processing Center
16 Association Drive, PO Box 360
Manchester, ME 04351-0360
Telephone: 207 623-2555    Fax: (207) 622-7086
Email: info@mhdpc.org