Feedback
Did this article resolve your question/issue?

   

Article

How the Connect XML Converters support HIPAA Compliance Levels (WEDI SNIP)

Information

 
TitleHow the Connect XML Converters support HIPAA Compliance Levels (WEDI SNIP)
URL Namehow-the-connect-xml-converters-support-hipaa-compliance-levels-wedi-snip
Article Number000181164
EnvironmentProduct: Connect XML Converters
Version: 6.2
OS: All Supported
Database: N/A
Application: N/A
Question/Problem Description
How the Connect XML Converters support HIPAA Compliance Levels (WEDI SNIP) 
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
There are seven levels of compliance given by the Strategic National Implementation Process (SNIP) group of the Workgroup for Electronic Data Interchange (WEDI). They are as follows:
  •     Integrity Testing
  •     Requirement Testing
  •     Balancing
  •     Situational Testing
  •     Code Set Testing
  •     Line of Business Testing
  •     Trading Partner Testing

What do they mean, and how does the current implementation of the XML Converters (DDXC 6.0) support them?

Level 1: Integrity Testing

Tests for valid segments, segment order, element attributes, verifying that numeric data elements have a numeric value, validation of X12 syntax and compliance with X12 rules.

The Connect XML Converters handle all of that transparently and completely.

Level 2: Requirement Testing

Tests for HIPAA Implementation Guide specific requirements like repeat counts, used vs. unused codes, elements and segments, and required or intra-segment situational data elements.

Connect XML Converters support all of this, with one small exception. HIPAA uses subsets of X12 messages. There are cases where there are some elements in the X12 message that are not used by HIPAA. We have not marked them as such in our repository, although there is nothing stopping us from doing so except for time. What this means is that if a user puts a value in an element marked as "not used," we won't flag it as an error. We do not consider this a critical issue.

Level 3: Balancing

Tests the transaction for balanced field totals, record or segment counts, financial balancing of claims or remittance advice and balancing of summary fields.

The Connect XML Converters automatically do these calculations; if there are any we don't do, it is because we missed something in the spec. We do allow the user to override the totals if for some reason they should feel the need, but the default is to calculate everything, including sums, totals, and hashes.

Level 4: Situational Testing

Tests specific inter-segment situations described in the HIPAA implementation guides (i.e. if A occurs then B must be present)

This is fully supported and enabled when the user specifies the intra=yes URI option.

Level 5: Code Set Testing

Tests for valid Implementation Guide specific code set values. Accepted code set values are: ICD–9-CM (International Classification of Diseases, 9th Edition, Clinical Modification), volumes 1-3, HCPCS (Health Care Financing Administration Common Procedure Coding System) except for level III or local codes and CPT-4 (Current Procedural Terminology, 4th Edition)

We check automatically for all of the code lists that are included in the WPC-EDI guides. Because different locations will use different subsets of ICD-9, ICD-10, HCPCS, etc., we have not bundled those codelists (some of them run into the tens-of-thousands of items, or more). The user can specify these either by the SEF editor, an XQuery program, or using the unknownCodelistValue callout in the EDIConverterListener and providing an external lookup source, such as a database. unknownCodelistValue(String segment, int pos, int sub, int tri, int rep, String element, String item) is called if the normal code list validation fails for an item. Returning null will cause the caller to force an exception if tbl=yes is set. Returning a non-null value will indicate that the passed code should be accepted as valid.

Level 6: Line of Business Testing

Specialized testing required by certain health care specialties. For example, hospice care, home oxygen treatment and ambulance service have unique data requirements for submitting claims to a payer.

This is where the specific line-of-business details are handled, and will be specific to each customer. XQuery or some other mechanism is ideal for this, since it deals with rules that span the document but are localized to the type of service (e.g. ambulance, chiropractic, podiatry, home health, psychiatry, etc.). A prepackaged application cannot supply this.

Level 7: Trading Partner Testing

Specialized testing between trading partners to ensure that data specific to conducting business between trading partners will process correctly. The Companion Guides deal with the specific requirements for transacting business between partners.

Because each vendor will have different requirements for source data and documents, this will be localized to each combination of line-of-business and health care agent. XQuery or something larger like DXSI would be ideal here.
Workaround
Notes
Last Modified Date2/2/2017 7:01 PM
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.