Frequently Asked Questions
This is a list of frequently asked questions from payer–submitters and the MHDO responses. It will be updated on an ongoing basis, as needed.
Question: What if some of the data being required is not available within our data warehouse?
Answer: 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. The new system gives users significant control over how to deal with this by overriding validation issues and providing reasons for not being able to meet the threshold.
Question: I have multiple subentities in my company. Do I have to use the same Administrative Contact for each?
Answer: No, in the Portal, accounts are initially setup with one Administrative Contact that has the ability to add or invite additional users, who can then be granted Administrative permissions. You can setup as many Administrative Contacts as necessary for your company’s processes.
Question: How do I register multiple subentities that will submit data under my company’s account?
Answer: If the subentities are essentially part of your company you can add users as Member Eligibility, Medical, Dental, or Pharmacy Contact and designate them as data users. If the subentity is an entirely different company you can add them as a Third Party Submitter.
Question: I’m a TPA with multiple employer sponsored plans. Do I need to register them all as Third Party Submitters?
Answer: No. The contracted TPA is the only entity that is legally responsible for the submission of healthcare claims processed for self-insured plans/plan sponsors/employer groups.
Reporting and Submission Requirements
Question: Who should I contact if I have questions about the reporting requirements and compliance?
Answer: Please contact Philippe Bonneau, Compliance Officer, Maine Health Data Organization at email@example.com or 207-287-6743.
Question: I did not have any claims activity during the last period (month or quarter). Do I still need to submit a file?
Answer: Yes, please submit a file with a header and trailer record count of 0.
Question: For the field- MC070 (Service Provider Country Code) can we use ’OT’, when we do not have a country name in the data?
Answer: Please leave the field blank when the country is not known.
Question: For MC038, DC031, and PC025, Claim Status, three of the current valid values are 01 – Processed as Primary, 02 – Processed as Secondary, and 03 – Processed as Tertiary; the 835 implementation guide, specified as the basis for the revised mapping, lists these three conditions as 1, 2, and 3, without the leading zero. Is this material? Will your systems accept both 01 and 1 or should we make a modification to include the leading zero?
Answer: The system will be able to accept both formats (with and without a leading zero).
Question: MC003, DC003, and PC003, Insurance Type/Product code now maps off of the 835 transaction set and there is an option to distinguish Dental Maintenance Organization business while the field ME003, Insurance Type/Product Code, which now maps off of the 271 code set, does not have an equivalent mapping option. This may cause a disconnect between the product typing across the member and claims files.
Answer: In consultation with payers, the MHDO has had to add values to these code sets in the past. If the need arises, we may have to do so again.
Question: The relationship codes I submitted are failing. Why?
Answer: Under the 5010 standard the codes “34 – Other Adult” and “76 – Dependent” are no longer acceptable for MC011, DC011, and ME012. These fields should be recoded with “G8 – Other Relationship” so the file will pass the validation.
Data Submission/Transfer Process
Question: Will the new compression/encryption process use a different field encryption methodology or will the file have to be field encrypted (through the web portal) before transmission to the FTP Server?
Answer: Sensitive information within files will no longer be protected using field-level encryption; instead, file-level encryption will be used. Submitters will use commercially available, payer-approved file compression and encryption software, rather than proprietary software created and distributed by the vendor.
Question: If we choose to submit files via SFTP are the files required to be zipped/encrypted prior to sending?
Answer: Yes. Submitters will use commercially available, payer-approved file compression and encryption software, rather than proprietary software created and distributed by the vendor. Specifications and instructions for file compression and encryption can be found in the User Guide.
Question: How will I find out if my submission failed?
Answer: All files will be validated within 24 hours of submission. Once the validation process has completed you will receive a notification email. Any validation issues found can be viewed and resolved on the Portal.
Question: Whom do I contact if I am having upload problems either via the Portal or SFTP?
Answer: The Portal Help Desk is available for any technical/system issues that a user may encounter. Customers of the Portal should expect support during regular business hours (8am-5pm EDT, Monday – Friday) within two hours of request. Below is the contact information for the Help Desk:
Toll-free Phone Number: 866-451-5876
Email Address: firstname.lastname@example.org
Question: Can I submit test files?
Answer: Yes, you may submit test files but they need to be named as such so they are not included in the data warehouse. In order to name them you must follow the naming conventions specified in the user guide using “TEST” as the payer ID. You can number the files if needed (i.e. TEST1, TEST2). The test file will be live until the evening site maintenance at 11:59 pm of the same day.
Question: We had submitted our files via SFTP but they aren’t showing up on the submission history screen on the MHDO portal page.
Answer: If files are submitted via SFTP that are not properly compressed and encrypted (example: .txt file), they will not show up on the submission history screens.
Question: Where does the MHDO Data Warehouse reside? Describe what protections are in place for system security.
The MHDO Data Warehouse systems reside within the National Opinion Research Center (NORC) secure facilities. These facilities have strictly controlled physical access and maintain boundary protection utilizing network firewalls, Intrusion Prevention System (IPS) and security monitoring using a unified situational platform. The IT environment is thoroughly documented and is compliant with NIST 800-53 Rev.3 standards. Security provisions are established and maintained to include:
- Managed firewall and IPS
- Configuration management baselines: FDCC\USGCB for laptops, Center for Internet Security (CIS) benchmarks for network and server systems
- Least privilege access to system boundary
- Continuous physical and system security monitoring
- Managed security policies using domain group policies for complex passwords and mandatory renewal
- Domain-managed virus protection
- Access control procedures for data and systems
- Virus and spam filtering of email
- Encryption, FIPS 140-2 Level 2 – laptops (Full Disk), VPN connection (2-factor authentication), Encrypted backups tapes
In NORC’s Data Enclave environment, which houses MHDO systems,- users are logically separated within their work area and unable to remove any information without prior authorization from MHDO. Any inbound or outbound files are managed and audited by the NORC Data Custodians.
Annual security tests are conducted by a third party IT security auditor. This auditor conducts a design-level review of controls that support the security of the Enclave using NIST Special Publications 800-53 (Moderate-Impact assets) as the security standard, and an analysis of risks to electronic protected health information (ePHI) in the Enclave as a result of any potential gaps., which are immediately addressed. The auditor evaluates the design and implementation of the following aspects of the NORC System Security Plan (SSP) through:
- Stating roles and responsibilities for ownership and stewardship of the SSP,
- Stating the risk assessment, methodologies, processes and documents,
- The certification and authorization of acquired and developed systems,
- Operational controls, including contingency and incident response plans and maintenance plans,
- Considerations of personnel management and facilities and physical security management,
- The integrity of information and the integrity of communications (network) systems,
- The control of access controls, including authentication of access accounts and the approved movement of data to zones of varying degrees of security,
- The appropriate selection of controls from the NIST 800-53 catalog of controls (as a result of FIPS 199 classification and the Risk Assessment), and
- The policies and process documentation (standards, procedures, guidelines and audit records, where applicable) for the selected controls from NIST 800-53.
In addition, these annual security tests include penetration testing and simulated denial-of-service attacks. The NORC Data Enclave was recently awarded a federal Authorization to Operate by USDA’s Economic Research Service.
The NORC Data Enclave complies with the following federal compliance guidance:
- NIST Special Publication (SP) 800-55, Security Metrics Guide for Information Technology Systems
- NIST SP 800-53, Recommended Security Controls for Federal Information Systems
- NIST SP 800-51, Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme
- NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems
- NIST SP 800-34, Contingency Planning Guide for Information Technology Systems
- NIST SP 800-26, Security Self-Assessment Guide for Information Technology Systems
- NIST SP 800-18, Guide for Developing Security Plans for Information Technology Systems
- Health Insurance Portability and Accountability Act (HIPAA) of 1996
- FIPS 200, Minimum Security Requirements for Federal Information and Information Systems
- FIPS 199, Standards for Security Categorization of Federal Information and Information Systems
- FIPS 191, Guideline for the Analysis of Local Area Network Security
- IEEE Std 829-1998, IEEE Standard for Software Test Documentation
The NORC Data Enclave IT Security Plan is fully compliant with the Federal Information Security Management Act, provisions of mandatory Federal Information Processing Standards (FIPS), and meets all of NIST’s IT, data, system and physical security requirements.
In addition to internal NORC confidentiality and ethics statements, all NORC Data Enclave employees must sign project specific Nondisclosure Agreements as specified in Commerce Acquisition Regulation (CAR) 1352.209-72, Restrictions against Disclosures.
NORC is in compliance with DOC IT Security Program Policy, section 4.5 and the NIST IT Security Management Handbook, including section 8.3 regarding policy on rules of behavior. The NIST Policy on IT Resources Access and Use must be followed for rules of behavior for this system.
The NORC Data Enclave is subject to the DoC IT Security Program Policy and Minimum Implementation Standards along with the IT security laws and federal regulations including:
- Public Law 107-347 E-Government Act of 2002 (FISMA included), Title V:
- Confidentiality Information Protection and Statistical Efficiency Act (CIPSEA).
- Public Law 200-253 Computer Security Act of 1987
- OMB Circular No. A-130 , Appendix III, Security of Automated Information Resources
- Department of Commerce Administrative Orders and
- NIST Administrative Manual Chapter 11.02 and the NIST IT Security
Question: Can the MHDO Portal can now handle files with 0 records?
Answer: Yes, however the header and trailer information must be included.
This is what the whole file should look like;
HD/TR = Header/Trailer
C12345 = Submitter/Payer code
DC = File type (Dental Claim)
201212*201212 = Date (December 2012)
0 = Count of Records in the File
Remember that empty fields still need quote mark text qualifiers.
Question: I am a new MHDO user and my group is required to upload historical files. Can I upload all of them to the MHDO Portal within a single zip file?
Answer: Please upload all historical files in the same way you upload current files. For example, if you are a monthly submitter, please submit the historical files within monthly uploads to the portal. Including more than one file in an uploaded zip file will result in a validation error.
Question: Do my files have to be named a certain way for data submission?
Example of a valid file name: C0756_201212ME01v01.txt
File names follow the same convention regardless of reporting frequency, and they’re made up of the following elements in the following order:
- Payer ID: The Payer ID should correspond to the Payer ID in the header of the file.
- An underscore symbol: “_”
- Period ending date expressed as CCYYMM (four-digit calendar year and two-digit month; for example, 201403 indicates a March 2014 end date). Quarterly data submissions should use the end date for the last month of the quarter. For example, the first quarter of 2014 would use 201403.
- File type: Member Eligibility (ME), Medical Claims (MC), Dental Claims (DC), Pharmacy Claims (PC).
- Sequence number: This is used to differentiate files with otherwise identical file names (for example, when two medical files are submitted during the same submission period). It’s expressed as a two-digit number, starting with 01. You must include the leading zero. The sequence numbering starts over with each new submission period.
- Version number: This is used to differentiate multiple submissions of the same file. This will be important if a file needs to be resubmitted to resolve an issue such as a validation failure. The letter v should be used, followed by two digits, starting with v01. You must include the leading zero. Original submissions of all files should be labeled v01. The Portal will not accept files that have the same name as an existing file.
- File extension (.zip, .7z, etc.)
Question: My file has structural and profile, ad hoc, or exemption level issues. Which should I clear first?
Answer: Structural validation issues should always be resolved first because they cannot be overridden through the portal. The only way to clear a structural issue is to resubmit a corrected file. When a file contains structural issues (i.e. a field is too long) subsequent validations may be inaccurate. By resolving structural errors first, other validations can be successfully performed and may clear up issues for you.
Question: My file has a structural issue saying the row is too long. Why?
Answer: Do not include an extra asterisk (*) at the end of a row or the validation system will detect it as an extra field and cause a structural failure on the file. Do not submit anything longer than required field length or it will cause a validation issue.
Question: My file is getting validation issues for some codes that I believe are correct.
Answer: If the codes in question are numbers confirm whether or not the standard requires a leading zero to be included. If the code does not match the standard exactly it will not be accepted. The one exception is for MC038, DC031, and PC025 for which codes with leading zeros and without leading zeros will be accepted.
Question: My company has a new validation or code list to submit. Where do I send it?
Answer: Please send all payer specific code lists to the Help Desk email@example.com.
Question: Is there a one-to-one correspondence with the company suffixes and their collection of submitter codes? How will you know which Validation Profile to use to validate my files?
Answer: Every file submitted has a header record with one payer ID. The payer ID includes the suffix, null or other. The system will look at that record and select the corresponding Validation Profile to use.
Question: Will my company’s suffixes be preloaded into the portal?
Answer: Yes, they will be preloaded into the portal. Any changes going forward will need to be communicated to and approved by MHDO.
Question: Can thresholds be lowered so my file passes?
Answer: The validation rules and thresholds were assessed and updated in early May 2014. This included the lowering of thresholds where appropriate. If a file is still failing a validation rule, users can override the issue.
Question: Why is the denominator different across different validation rules within a single file?
Answer: The denominators vary due to the validation rule criteria. While the majority of rules look at all records within a file, some have a condition that only look at a subset of applicable records. For example, some rules only evaluate inpatient records. If a condition is present it will be described in the Validity Criteria of a given rule.
Question: My failed due to Duplicate File Name structural issue. How do I fix this?
Answer: This failure was caused by submitting a file with the exact same name as a previously submitted file. You need to resubmit the file with a new file name with a new version or sequence number. This is explained in the Naming Files Before Compression and Encryption section of the User Manual.
Sequence number: This is used to differentiate files with otherwise identical file names (for example, when two medical files are submitted during the same submission period). It’s expressed as a two-digit number, starting with 01. You must include the leading zero. The sequence numbering starts over with each new submission period.
Version number: This is used to differentiate multiple submissions of the same file. This will be important if a file needs to be resubmitted to resolve an issue such as a validation failure. The letter v should be used, followed by two digits, starting with v01. You must include the leading zero. Original submissions of all files should be labeled v01.
Question: If there are no issues remaining on the Validation Issues screen, does that mean that the files have passed?
Answer: Yes. When there are no remaining validation issues, your file is then considered passed. If the status of your file does not update to show a passed status and still shows no validation issues, please contact the Help Desk.
Question: I requested an exemption for my file, but it is still showing up as failing and there is still an issue for that validation rule. What happened?
Answer: The date range in the exemption request form now covers the data date, not the submission date. For example, when submitting January MC files in February and a user needs to request an exemption, they must select a start date of January. If February is selected, then exemption will not be activated until the next month’s MC file is submitted.
Question: I am submitting older data, why isn’t it passing?
Answer: Submission periods are locked for data periods already released to end users (data are released every quarter). When submitters try to submit data for a locked period, a Submission Period Locked structural validation issue occurs. This issue must be resolved before all other validation issues. If the data are less than a year old, the validation issue will be cleared as soon as the information is provided by the user. Submissions of data older than one year will require approval from MHDO before the issue will be cleared.
Question: When will Profile and Exemption-Level Overrides be reset?
Answer: All existing profile and exemption-level overrides expire yearly (Usually February). Submissions that occur after this reset will be evaluated against all validation rules. New profile and exemption-level overrides will have to be requested as needed. MHDO will do this reset each year to encourage payers to review whether their data quality has improved.
Question: Will I be able to view my terminated Profile and Exemption-Level Override history?
Answer: Yes, when creating a new Profile or Exemption Override after the reset, or at any time by clicking “View Override” on an overridden field, you will be able to see a record of past overrides for that field including both the reason for the override and any notes as to why the override was terminated. You can also view the history of how your data have performed against the validation rules across all your submissions in the Validation Report.
Question: Are default SSN values accepted in submitted data?
Answer: All data submission SSN Validation Rules will cross-reference a list of invalid SSN values including those listed by the Social Security Administration. Using these values in submitted data will result in a failed status on the file.
Question: What common issues cause the Decryption Failed message?
Answer: 1. No password was used when zipping 2. The wrong password was used when zipping 3. The zip contains more than one file