HIPAA Data Compliance Parameters

Parameters for the HIPAA Data Compliance are set in the JSON formatted parameter file, hipaa_data_compliance_parameter.json.

This file contains a meaningful grouping of parameters:

GeneralValidation
ValidationLevels
Acknowledgments
Tuning

The following table has details of the setting allowed. If any field is not included in the hipaa_data_compliance_parameter.json file, the default will be used.

In the following table, the * (asterisk) indicates the default value.

Since the format of this parameter file is JSON, the name and parameter values that are text strings must always be enclosed in double quotes. The value, if Boolean is true or false, does not need to be quoted. A few of the parameters are numeric values, and they do not need to be quoted either.

Examples:

"Enabled": false

"WhenIfEnabled": "Errors"

It is recommended that a JSON aware editor is used, that will flag invalid syntax such as missing or extra commas and quotes.

Parameter tag name	Values	Description
Environment ProductName	H	The ProductName parameter is used to identify the product that has invoked the compliance check application. If parameter is used, it should always be H.
Environment OperatingSystem	L A U M W	The OperatingSystem parameter is used to override the dynamic determination of the UNIX operating system from the format of the input data file. It is always recommended to specify the operating system using this parameter. Allowable settings include: L (Linux), A (AIX), U (USS), M (MVS - z/OS ), W (Windows)
Environment BaseMapDirectory	C:\\DIR\\ Or /dir/	The BaseMapDirectory parameter specifies the directory for compiled maps that will be executed by hipaa_data_compliance.mmc via the RUN function. There is NO default setting for this parameter. If the parameter is not specified, then the directory from which hipaa_data_compliance.mmc is being executed will be used. This parameter cannot be used for z/OS. Note: Final slash must be used. Since the input is in JSON Format back slash must be doubled if specifying directory on Windows.
Environment BaseExitDirectory	C:\\DIR\\ Or /dir/	The BaseExitDirectory parameter specifies the directory for executables invoked via the EXIT function. There is NO default setting for this parameter. If the parameter is not specified, then the system library path will be used. This parameter cannot be used for z/OS. Note: Final slash must be used. Since the input is in JSON Format back slash must be doubled if specifying directory on Windows.
Environment DataBaseQueryType	JDBC MONGO*	The DataBaseQueryType is used to indicate the type of database access for Code List validation in Type 5 and higher checks. The MRN file must still be updated for the specific access parameters.
GeneralValidation 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, and also valid data that must be processed for rules only supported by the detailed compliance check 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 both 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.
GeneralValidation RejectUnsupported5010Version	true* - Reject unsupported 5010 versions in the envelop checking process. false - Don't reject unsupported versions, and validate them at currently supported versions.	Indicates whether to reject an unsupported HIPAA 5010 version or whether to validate the data to the currently supported errata version.
GeneralValidation BINSegXMLValidation Enabled	true* - Validate Contents of BIN segment according to SchemaOrWellFormed Value. false - Never validate the contents of the BIN segment.	Indicates the validation level for XML BIN/BDS segment content.
GeneralValidation BINSegXMLValidation SchemaOrWellFormed	Schema - Validate the contents of the BIN segment for proper XML formatting and against the schema. XML - Validate the contents of the BIN segment for proper XML formatting and against the schema.	Type of validation to perform on BIN/BDS segment.
GeneralValidation DuplicateISAChecks	true* false	Indicates whether interchange (ISA) envelopes should be checked for duplicates.
GeneralValidation DuplicateIGSChecks	true false*	Indicates whether Functional Group control numbers should be checked for duplicates within an interchange.
GeneralValidation DuplicateSTChecks (No I)	true* false	Indicates whether transaction set (ST) envelopes should be checked for duplicates.
GeneralValidation Allow_GS_Leading_0	true false*	Indicates whether to allow leading zeros in the Functional Group control number (such as 0001) in the GS and GE segments.
GeneralValidation ClaimLevelRejection Enabled	true false*	Indicates whether the transaction set is still accepted and the claim(s) in error are removed from the valid data. This parameter is only available to be used when the input HIPAA EDI data is a Claim (837).
GeneralValidation ClaimLevelRejection Level	All – Only reject transaction set when all claims are in error or when an error is outside the Provider loops. If error is at the provider, subscriber, or patient level, all claims for that provider, subscriber, or patient will be rejected. Claim - Reject transaction set when all claims are in error, or when error is outside of Claim Loop.	If the ClaimLevelRejection Enabled is true, this controls at which level the valid and invalid claims are separated.
ClaimLevelRejection DuplicateCLMCheckFullSegment	true false*	The Duplicate CLMCheckFullSegment 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 true - 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 true is used
Tack HTMLOrJSON	HTML* JSON BOTH	Use the HTMLOrJSON parameter set to JSON or BOTH to optionally create ../data/compliance_check_TAck.json in output card 13. When either HTML or BOTH is used, the /data/compliance_check_TAck.html is produced in output card 11. Note: Both creation and content are still controlled by the other parameters in the Tack group. This parameter only controls how the Tack is formatted.
ValidationLevels Type1 Enabled	true false*	Indicates whether WEDI/SNIP Type 1 checks should be performed on the input data. (Note any Type 1 error will be found if Type 2 is enabled; this only runs the Type 1 validation as a separate step, so it is not recommended).
ValidationLevels Type2 Enabled	true* false	Indicates whether WEDI/SNIP Type 2 checks should be performed on the input data.
ValidationLevels Type2 RelaxedStructureCheck	true false*	Indicates whether relaxed structure should be performed on the input data if it fails the type 2 structure checking process. This check will only be performed if there are errors found during the type 2 structure checking process - if no errors are found, it will be bypassed. It also can only be executed if type 2 checks are enabled.
ValidationLevels Type3 Enabled	true* false	Indicates whether WEDI/SNIP Type 3 checks should be performed on the input data.
ValidationLevels Type4 Enabled	true* false	Indicates whether WEDI/SNIP Type 4 checks should be performed on the input data.
ValidationLevels Type5 Enabled	true false*	Indicates whether WEDI/SNIP Type 5 checks should be performed on the input data.
ValidationLevels Type6 Enabled	true false*	Indicates whether WEDI/SNIP Type 6 checks should be performed on the input data.
ValidationLevels Type7 Enabled	true false*	Indicates whether WEDI/SNIP Type 7 checks should be performed on the input data.
ValidationLevels Type7 RejectLevel	Errors	Exceptions found in the custom user exit are treated as errors, and data will be rejected.
ValidationLevels Type7 ExitType	Java C None*	Indicates the language in which the custom user exit is written.
ValidationLevels Type7 ExitName	(User specific value) None*	Indicates the name of the custom user exit library name if the exit is written in C or jar file if the exit is written in Java.
ValidationLevels Type7 ExitFunction	(User specific value) None*	Indicates the name of the custom user exit function name within the library or jar file.
Acknowledgments TA1 Enabled	true false*	Indicates whether the results from the WEDI/SNIP Type 1 interchange envelope checks should be reported using the X12 standard TA1 segment.
Acknowledgments TA1 WhenIfEnabled	Errors* - Generate an X12 standard TA1 for the interchange only when the results of the compliance check indicate the presence of Type 1 errors in the interchange envelope. Always - Always generate an X12 standard TA1 for all interchanges even if compliance check does not indicate the presence of Type 1 errors in the interchange envelope. Requested - Generate an X12 standard TA1 for all interchanges based on the value in the input ISA14. Input ISA14 value of 0 - No Interchange Acknowledgment Requested will identify the same behavior as Never. Input ISA14 value of 1 - Interchange Acknowledgment Requested (TA1) will identify the same behavior as Always.	If Enabled, determine when the TA1 is generated.
Acknowledgments TA1 Separate	true* false	Indicates whether TA1 acknowledgments should be created in a separate response transmission or be combined with the response transmission that contains the 997 acknowledgment transaction sets.
Acknowledgments 997 Enabled	true false*	Indicates whether the results from the WEDI/SNIP Type 1 checks should be reported using the X12 standard 997 transaction set. If Type 1 checks are not enabled, this will be set to false.
Acknowledgments 997 WhenIfEnabled	Errors* - Generate an X12 standard 997 for the interchange only when the results of the compliance check indicate the presence of Type 1 errors in the interchange Always - Always generate an X12 standard 997 for all interchanges even if compliance check does not indicate the presence of Type 1 errors.	Indicates when the results from the WEDI/SNIP Type 1 checks should be reported using the X12 standard 997 transaction set.
Acknowledgments 997 DetailMax	(User-specified numeric value) 9999*	Indicates when we should stop producing detailed 997 error information for a single transaction. If the number of error lines, not total errors, to be produced in the 997 for the received transaction exceeds this limit, then the logic to generate the detailed error information in the AK3/AK4 loop will be bypassed. As the number of errors for a single transaction increases, the processing time required to detect and report these also increases, so increasing this limit will decrease performance when processing transactions containing numerous errors. The setting for this value will determine the maximum number of error lines produced in the 997 for a single transaction.
Acknowledgments HIPAA_TA1 Enabled	true false*	Indicates whether the results from the WEDI/SNIP Type 2 interchange envelope checks using HIPAA specific code values should be reported using the TA1 segment.
Acknowledgments HIPAA_TA1 WhenIfEnabled	Errors* - Generates an X12 standard TA1 for the interchange only Type 1 errors present in the interchange envelope. Always - Always generates an X12 standard TA1 for all interchanges, even if Type 1 errors are not present in the interchange envelope. Requested - Generates an X12 standard TA1 for all interchanges based on the value in the input ISA14. Input ISA14 value of 0 - No Interchange Acknowledgment Requested will identify the same behavior as Never. Input ISA14 value of 1 - Interchange Acknowledgment Requested (TA1) will identify the same behavior as Always.	If Enabled, determine when the TA1 is generated.
Acknowledgments 999 Enabled	true false*	Indicates whether the results from the WEDI/SNIP checks should be reported using the HIPAA specific 999 transaction set.
Acknowledgments 999 WhenIfEnabled	Errors - Generates only when WEDI/SNIP type errors are present in the interchange. Always* - Always generates even if WEDI/SNIP type errors are not present in interchange.	Indicates when the results from the WEDI/SNIP checks should be reported using a HIPAA specific 999.
Acknowledgments 999 IK3MissingSeg	true false*	For implementation dependent missing segments (I6), use true for this setting if the missing segment is to be reported 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, the segment location in the transaction where it was determined the missing segment was not present, or the end of a loop. Use false to report the existing segment, which caused the requirement for the missing segment to be reported in the IK3.
Acknowledgments 999 DetailMax	(User specified numeric value) 9999*	Indicates when we should stop producing detailed HIPAA 999 error information for a single transaction. If the number of error lines, not total errors, to be produced in the HIPAA 999 for the received transaction exceeds this limit, then the logic to generate the detailed error information in the AK3/AK4 loop will be bypassed. As the number of errors for a single transaction increases, the processing time required to detect and report these also increases, so increasing this limit will decrease performance when processing transactions containing numerous errors. The setting for this value will determine the maximum number of error lines produced in the HIPAA 999 for a single transaction.
Acknowledgments 277CA Enabled	true false*	Indicates whether the results from the Claim Level Rejection process should be reported using the 5010 277CA transaction set.
Acknowledgments 277CA WhenIfEnabled	true false*	Indicates when the results from the WEDI/SNIP checks should be reported using a 277CA.
Acknowledgments 277CA Level	Provider* - 277CA reports details at the Provider Level. This option will not provide specific details on each claim, only on the totals accepted/rejected for each Provider. Claim - 277CA reports details at the Claim Level. This option will provide specific details on each Claim within the transaction. All - 277CA reports all details at both Provider and Claim. If there are no errors, then the reporting will include the Patient/Claim details.	Indicates the level at which the HIPAA 277 Claims Acknowledgment reports. It can show details at the Provider level, or it can show details down to the Patient/Claim Level. This parameter will only have an impact if the Claim Level Rejection is enabled and the input HIPAA EDI data is a Claim (837). If there are no errors in the HIPAA EDI 837 data, then reporting will only go to the Provider Level, regardless of the setting. Using options Claim or All may impact performance if there is a large quantity of claims in the data.
Acknowledgments 277CA UniqueBHT03	true false*	Indicates whether to produce a BHT03 value based on the interchange, functional group, and transaction control numbers of the source 837 being validated. If false, 277X2140001 is always set as a value for the BHT03 element.
Acknowledgments TACK Enabled	true false*	Indicates whether the Translated Acknowledgment Report will be produced. This report transforms the 997 and 999 acknowledgments into a more readable report.
Acknowledgments TACK WhenIfEnabled	Errors* - Generate only when WEDI/SNIP type errors are present in the interchange. Always - Always generate even if WEDI/SNIP type errors are not present in interchange.	Indicates when the results from the WEDI/SNIP checks should be reported using Tack report.
Acknowledgments TACK IncludeAccepted	true false*	Indicates the level of reporting in the Translated Acknowledgment Report. If true, report all data, including those accepted and rejected. If false, only generate the report based on the data in error.
Acknowledgments TACK TAck_EDI	Full* – Generates TAck_EDI.html file with all the transactions in the data. Partial - Generates TAck_EDI.html file with only the transactions in error. None	Indicates whether the TAck_EDI file, which is a html tagged version of the transactions being validated, is produced with all the original data, or just the transactions that have errors reported. If Acknowledgments Tack Enabled is false, this parameter is not used. If Acknowledgments Tack Enabled is true, the default for this is Full. Options Partial or None may help overall performance.
Acknowledgments LoopIDInAck Enabled	true* false	Include loop identifier in the acknowledgment. If a 997 is requested and this parameter is set to true, then the AK303 will contain the loop identifier of the segment in error. If a 999 is requested and this parameter is set to true, then the IK303 will contain the loop identifier of the segment in error.
Acknowledgments LoopIDInAck includeIDForAll	true false*	Indicates whether to include the functional group control number in the grouping of functional groups within an acknowledgment. If the setting is false, only the GS02, GS03, GS07, and GS08 are used to determine a unique functional group for reporting in the acknowledgment. If the setting is true, then the GS06 is also included in the determination.
Acknowledgments IncludeISA13InAcks	true false*	The IncludeISA13InAcks 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 true, the ISA13 value of the input transmission file will be used. If the parameter is set to false, 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.
Acknowledgments AckFunctionalGroups IncludeGS06	true false*	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 false, 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 true, the number of functional groups generated in the acknowledgment will depend on the input.
Acknowledgments AckFunctionalGroups UseInputFunctionalGroup	true false*	Create functional group in acknowledgment based on functional groups in the input, regardless of any GS values in the input. The number of functional groups in the acknowledgment will be the same as the number of functional groups present in the input.
Tuning Paging	-P64:8*	Indicates the page size and page count to be used for the execution of compiled maps that will be executed by hipaa_data_compliance map with the RUN function. The first number is Page Size, and the second number is page count. The page size value may be an even integer between 2 and 1024. The page count may be an integer between 1 and 9999. Note: In general, larger page sizes and count settings will improve overall map performance when input data transmission is large. Determining the optimal page settings may require some experimentation. This setting is not used for all run maps that are called.
Tuning Audit	-AEWU*	Indicates the audit log setting to be used for the execution of compiled maps that will be executed with the RUN function.
Tuning WorkFile	-WDU*	Indicates work file setting to be used for the execution of compiled maps that will be executed with the RUN function.
Tuning LengthOfDataElementInError	(User Specified numeric value between 1 and 99) 50*	Used for customizing the length of the value produced in the AK404/IK404 elements of the reporting acknowledgments. Setting this to a value higher than the default may have a negative impact on performance. There may be cases where the entirety of the data in the file being validated is not placed on the acknowledgment even when this parameter is configured to its maximum value: When the length of data being reported exceeds the maximum parameter value or when the length of data exceeds more than twice the defined element length if the defined element length is > 32 characters. The maximum size is 99, and the default size is 50.
Acknowledgments 824 Enabled	true false*	Indicates whether the results from the WEDI/SNIP Type 6 and 7 checks reported as a warning should be reported using the 824 transaction set.
Acknowledgments 824 WhenIfEnabled	Errors - Generates only when WEDI/SNIP type 6 or 7 warnings are present in the interchange. Always* - Always generates even if WEDI/SNIP type 6 or 7 warning are not present in interchange.	Indicates when the results from the WEDI/SNIP checks should be reported using a HIPAA specific 824.
Acknowledgments 824 DetailMax	(User specified numeric value) 9999*	Indicates when we should stop producing detailed 824 warning information for a single transaction. If the number of warning lines, not total errors, to be produced in the 824 for the received transaction exceeds this limit, then the logic to generate the detailed information in the TED loop will be bypassed. The setting for this value will determine the maximum number of error lines produced in the 824 for a single transaction.
GS08	Standard Industry	Standard - Use the X12 standard value (i.e., 005010) in the GS08 element of the 824. Industry - Use the HIPAA or industry-specific value (e.g., 005010X186A1) in the GS08 element of the 824.
Acknowledgments 999 DetailMax	(User specified numeric value) 9999*	Note: To further reduce processing time on transactions with many errors, higher level validation may be skipped if the max is hit during Type 2 validation.