HIPAA Compliance Check Parameters
Parameters used for the Compliance Check application are set in the compliance_check_5010_paramater.dat file.
The settings in this file can be edited, and take effect the next time that the Compliance Check application is executed. There is no need to rebuild or re-deploy maps. This file contains data records that adhere to the convention of Tag_Name="Value".
The following table describes the parameter tag names and values used by the Compliance Check application.
In the following table, the * (asterisk) indicates the default value.
| Parameter tag name | Values | Description |
|---|---|---|
| HIPAA_997_Enabled parameter | No - Never generate a HIPAA-specific 997 transaction
even if the results of the compliance check indicate the presence of Type 1 errors. Yes* - Always generate a HIPAA-specific 997 transaction for all interchanges, even if the compliance check does not indicate the presence of Type 1 errors. |
Indicates whether the results from the WEDI/SNIP Type 1 check are reported by the HIPAA-specific 997 transaction set. This parameter is only available to be set when the highest level of HIPAA Validation selected is Type 1. If higher levels of HIPAA validations are selected, this parameter is not used. |
| HIPAA_Type_n_Checks_Enabled
Note: Where n is an integer 1-4. |
Yes - Perform Type n checks on the data. No - Do not perform Type n checks on the data. |
Used to indicate whether WEDI/SNIP Type n checks should be performed on the input data. See the HIPAA_Type_n_Checks_Enabled details documentation for more information about this parameter. |
| XML_Validation | Never* - Never validate the contents of the BIN
segment. XML - Validates the contents of the BIN segment for proper XML formatting. Schema - Validate the contents of the BIN segment for proper XML formatting and against the schema. |
Indicates the validation level for XML BIN/BDS segment content. The parameter is used to indicate whether the data in the BIN segment of the 4050 275 transaction set is to be validated and to which level it is to be validated. |
| HIPAA_Claim_Level_Rejection |
N[O] - Reject the Entire transaction regardless of the location of the error Y[ES] - Reject transaction set when all claims are in error or when an error is outside the Claim Loop. A[ll] - Only reject transaction set when all claims are in error or when an error is outside the Provider loops. If the error is at the Provider, subscriber or patient level, all claims for that provider, subscriber or patient will be rejected. |
Indicates whether the transaction set is still accepted with an AK501=E (errors accepted), and the claim, or claims, in error are removed from the valid data. This parameter is only available when the input HIPAA EDI data is a Claim 837. |
| HIPAA Claim Level 277CA Reporting | Never* - Never generate a 277CA even if the results of
the compliance check indicate the presence of errors in 837 Claims input
data. Exceptions - Generate a 277CA for the interchange only when the results of the compliance check indicate the presence of errors in the 837 Claims input data. Always - Always generate a 277CA for all interchanges even if the compliance check does not indicate the presence of errors in the 837 Claims input data. |
Indicates whether the results from the Claim Level Rejection process are reported using the 5010 277CA transaction set. |
| HIPAA_Claim_Rejection_Level | Provider* - This option is recommended for performance.
The 277CA reports details at the Provider level. This option does not provide specific details on
each claim, only on the totals that are accepted and rejected for each
Provider. Claim - The 277CA reports details at the Claim level. This option provides specific details on each claim within the transaction. This option might impact performance if there are a large number of claims in the data. |
Indicates the level at which the HIPAA 277 Claims Acknowledgment reports. It
can show detail at the Provider level, or it can show details down to the Patient/Claim
level. This parameter has an impact only when the HIPAA Claim Level Rejection envelope parameter is set to Yes, and the input HIPAA EDI data is a Claim (transaction set 837). The default setting is Provider. If there are no errors in the HIPAA EDI 837 data, reporting goes to the Provider level regardless of the setting. |
| Duplicate_CLM_Check_Full_Segment | Y[ES] N[O]* |
The Duplicate_CLM_Check_Full_Segment controls whether just CLMO1 or the full CLM segment is used to determine if claim-level rejection processing can continue for this transaction. If the parameter is set to Y[ES] - Disable Claim level rejection if the entire CLM segment is not unique for all claims in the transaction. Note: Only CLM01 is used to populate the TRN information in the 277CA,
so the user may have to handle any ambiguity in the resultant acknowledgment if
Y[ES] is used
|
| 277_REPORT_ERROR_STC | Y[ES] N[O]* |
Set the sub elements in the STC01 element at all 277CA and 277DR loop levels to reflect if all valid or an error was detected at that level or below and include a valid entity code instead of the generic Ack/Receipt code. |
| HIPAA_Tack_Enabled | Yes - Generate No* - Do not generate. Summary – Generate Translated Acknowledgement file without the Tack_EDI.html Partial - Generate Translated Acknowledgment file and the Tack_EDI.html file, but the Tack_EDI.html file only contains the transactions in error. |
Determines whether the Translated Acknowledgment Report is produced. This report transforms the acknowledgments into a readable report. |
| HIPAA_Tack_Accepted | Always - Generate accepted error
report. Exceptions* - Generate error report only. |
Determines what level of reporting appears on the Translated Acknowledgment Report. The options are to produce the report for all data (accepted and rejected) or to only generate the report based on the data in error. This setting only affects the content of the compliance_check_Tack.html file, not the Tack_EDI.html file. |
| Validation_Method | Map* Compliance Both |
Map - This default setting sends all data through the
pass-through validation maps and only the invalid data goes through the subsequent
processing. This is the recommended, and the default
setting. Compliance - This setting causes all data to be passed to the detailed processing done by the Compliance Check application. Both - This setting causes all data to be processed by the pass through validation maps and the detailed compliance check validation. If there is a large amount of data, this option can slow the process. This option is used for troubleshooting purposes, logic modules, or both. |
| HIPAA_Relaxed_T2_Structure_Check_Enabled | Yes - Perform relaxed Type 2 structure checks if
WEDI/SNIP Level 2 structure checking fails. No* - Do not perform relaxed Type 2 structure checks on the data. |
This parameter indicates whether the relaxed structure will be performed on
the input data if the data fails WEDI/SNIP Type 2 structure checking. This processing is performed only if errors are found during Type 2 structure checking. If errors are not present, this processing is bypassed. Also, this new processing is only executed when Type 2 checks are enabled. If only Type 1 checking is enabled, the setting is ignored. |
| HIPAA_277CA_Unique_BHT03 | Y[ES] - Produce a BHT03 value based on the interchange, functional group, and transaction control numbers of the source 837 being validated. N[O] - 277X2140001 is always set as a value for the BHT03 element. |
If claim level rejection is enabled, this parameter controls the value created for the BHT03 Element in the 277CA output. |
| LoopId_In_Acknowledgment | N[O] - No value reported. Y[ES] - Report Loop ID value (i.e. 2310). A[LL] - Include loop id for Element level CTX segment and for errors found in structure validation if available. |
This parameter indicates whether the loop identifier is required on the acknowledgment. (Will be reported in AK303 of 997 and IK303 in 999. |
| Include_ISA13_In_Acks |
Y[ES] N[O]* |
The Include_ISA13_In_Acks parameter is used when it is desired to use the ISA13 (control number) of the input transmission file for acknowledgments produced. If the parameter is set to Y[ES], the ISA13 value of the input transmission file will be used. If the parameter is set to N[O], a default control number will be used. Note: In the case of multiple interchanges in the input transmission,
the ISA13 of the first interchange will be used, as only one interchange is produced in the
acknowledgments.
|
| Include_GS06_In_Grouping |
Yes - Include GS06 in grouping for acknowledgment. No - Do not include GS06 in grouping for acknowledgment. Always - Create functional group in acknowledgment based on functional groups in input. |
TheInclude_GS06_In_Grouping parameter indicates whether to include the functional group control number in the grouping of functional groups within an acknowledgment. It does NOT affect the value of GS06 in the acknowledgment generated, which always starts with 1. If the setting is No, only the GS02, GS03, GS07, and GS08 are used to determine a unique functional group for reporting in the acknowledgment. So if the input has multiple functional groups with different control numbers (GS06) but have the same values for GS02, GS03, GS07, and GS08, the acknowledgment information is grouped into a single functional group in the output. If the setting is Yes, the number of functional groups generated in the acknowledgment will depend on the Input. If the setting is Always, functional groups in the acknowledgment are determined by the number of functional groups present in the input. |
| Paging_Parameter | 8* | This parameter specifies the page count used for the execution of most run
maps from within the compliance check. The page count might be an integer 1 - 9999. The default is 8 pages. |
| Paging_Parameter | 64* | This parameter specifies the page size (in Kb) to be used for the execution of run maps from within the compliance check. The page size might be an even integer 2 - 1024. The default setting is 64 Kb. In general, larger page sizes and count settings improve overall compliance check performance when processing transaction sets are large. |
| Allow_GS_Leading_0 |
Y[ES] N[O]* |
The Allow_GS_Leading_0 parameter indicates whether to allow leading zeros in the Functional Group control number in the GS and GE segments. Allowable settings include: Y[ES] - Allow leading zeros in group control numbers, such as 0001. N[O] - Do not allow leading zeros. |
| 999_IK3_Missing_Seg |
Y[ES] N[O]* |
For implementation dependent missing segments (I6), use Y[ES] to report the missing segment in the IK3. This will result in more information in the 999 by allowing the existing segment to be included in a CTX segment. Since the segment is missing, the segment position indicated will vary - it may be the position of the existing segment that caused the requirement, or the segment location in the transaction where it was determined the missing segment was not present, or the end of a loop. Use N[O] to report the existing segment that caused the requirement for the missing segment in the IK3. |