Developer Resources

What is a general overview of Chiapas EDI?

Chiapas EDI is a development platform focused on enabling enterprises to work directly with managed care healthcare EDI files, such as eligibility, billing and remittances.  It is composed of a ‘Chiapas Studio’ oriented towards developing new transactions, as well as the a background automation system and job control system.  The distribution database contains sample data and workflows oriented toward common business scenarios.  Finally, all of the mappings present in all of the specifications is documented within pre-generated HTML files.

What distinguishes Chiapas EDI from other EDI platforms?

Probably the most single most significant thing is that this platform was developed by and for healthcare developers in order to reduce the complexity burden on the developers.  Even though the HIPAA Implementation Guides describe a highly complex set of data protocols, Chiapas EDI enables the encoding of any compliant EDI file with a single stored procedure call, and decoding EDI files can be done with no programming at all.  

The Chiapas EDI distribution fully describes every valid mapping, as well as provides a number of default workflows and sample files to get started.

What documentation comes with Chiapas EDI 2014?

The primary source of documentation is the included user manual located in C:\chiapas\docs\ChiapasUserManual.pdf.  The individual mappings for the specifications as well as Addenda changes to the base mappings are located in the C:\chiapas\docs\CGIF folder.

What specifications does Chiapas EDI 2014 support?

• 270 – Health Care Eligibility Benefit Inquiry
• 271 – Health Care Eligibility Benefit Inquiry Response
• 276 – Health Care Claim Status Request
• 277 – Health Care Claim Status Response
• 277 CA – Health Care Claim Acknowledgment
• 278 REQ – Health Care Services Review-Request for Review
• 278 RESP – Health Care Services Review-Response
• 820 – Payroll Deducted and Other Group Premium Payment for Insurance Products
• 820X – Premium for Health Insurance Exchange
• 824 – Application Reporting
• 834 – Benefit Enrollment and Maintenance
• 835 – Health Care Claim Payment/ Advice
• 837 D – Health Care Claim: Dental
• 837 I – Health Care Claim: Institutional
• 837 P – Health Care Claim: Professional
• 999 – Transaction Acknowledgment
• TA1 Transaction Acknowledgment

Each transaction set is fully implemented in both 4010 and 5010 versions with all published Addenda. The HIPAA Implementation Guides are copyrighted and controlled materials available at the X12 website

Can the software be used for real-time transactions?  Does it have large file support?

Yes, and yes. Smaller transactions can generally be created or parsed in real-time. The software can handle multiple files simultaneously and fully utilize server resources. Large transactions can be handled if the server has the RAM available. The software is 64-bit and capable of handling large files. Note: Very large files may not be able to be displayed on the Chiapas Studio GUI display elements, but can still be processed through the system.

What is Chiapas EDI Version 1, and how is it related to Chiapas EDI 2014?

Chiapas EDI Version 1 was created in 2003 and licensed and used in several San Francisco Bay Area enterprises, including one HMO where it was used in production for a decade. It was released as open source in 2005, and has since been downloaded thousands of times, and there are companies that still use it today.

Chiapas EDI 2012 was a complete rewrite to evolve the technology to be a professional developed and supported EDI solution for corporations of all tiers. Chiapas EDI 2014 built upon 2012 and greatly extended the ‘out-of-the-box’ transformation functionality.

Whenever we decode a file, we see the identifiers appear but never see the qualifiers get mapped. Why is this?

Qualifiers represent metadata, in other words, information that provides context to other information. The design of Chiapas EDI 2014 is focused on minimizing the metadata an analyst needs to know about in order to get productive with EDI. For this reason, all identifier/qualifier pairs are represented within a single column mapping within Chiapas EDI. For this reason, many specific elements have many possible mappings because the preceding element contains a number of qualifiers. In this way, the mappings are more aligned with business information than they are with EDI formatting, and are therefore easier to work with.

Can the software test the integrity of HIPAA files?

Yes, the software package supports Level 1 and Level 2 SNIP integrity testing, as defined on pages 15 and 16 on the SNIP whitepaper.  Generally, this fully covers the basic syntax of the transaction.

When developing a new outbound claim file using a stored procedure, I am noticing the Claim loop repeat multiple times in the output file – why are these erroneous loops occuring?

One of the jobs of the Chiapas EDI encoding engine is to translate a ‘Flat’ data source like a stored procedure into an internal hierarchical format that mirrors an EDI file. In a Flat data source, much of the data is repeated across successive rows – in fact, the only data that should be different between different rows is when a new loop occurs.  The encoder engine looks for ‘deltas’ between successive rows to determine when to create a new iteration of an outer loop such as the 2300 Claim Header loop or a new transaction set.

Problems arise when data is provided to the encoding engine that cause unplanned ‘deltas’. This will cause unwanted loop iterations. For example, let’s say there is a problem in the mapping of the Claim ‘Place of Service’ field that causes it to have a different value for a certain procedure code:

L2300_S01_CLM01_PATNT_CONTRL_NR	L2300_S01_CLM05_01_PLAC_SVC_CD	L2400_S01_LX01_ASGND_NR
000010	11	1
000011	11	1
000011	12	2
000011	11	3

This will create four iterations of the CLM segment when the business intent would be to create just two. The first CLM will be associated with Patient Control Number 000010, which is correct. The second CLM will be triggered by the new Patient Control Number 000011. The erroneous third CLM segment will be triggered because the Place of Service code mapping is 12 instead of 11 as it was on the previous line. Finally, the fourth erroneous CLM segment will be generated because the Place of Service code changes back to 11.

To repair this issue, the developer needs to ensure that mappings associated to a particular iteration of a loop on the outbound EDI stay consistent with that iteration.  If a claim has three service lines, then only the data for those service line mappings should change for that claim – the claim mappings will be the same.

What is an example for developing a new outbound EDI process with Chiapas EDI 2014?

At a high level, to develop any outbound process you will need the companion guide for your trading partner (if available), the HIPAA Implementation Guide for the transaction you are submitting, and of course you will need the enterprise data that you intend to submit.

This answer will focus on the easiest critical path for development, which is via a stored procedure. Chiapas EDI comes with thirteen SQL Views as part of the distribution database that can create valid EDI files using the included mock healthcare data. These views represent established pipelines for creating EDI files, so they provide a foundation for creating new processes.  However, SQL Server does not guarantee specific ordering of rows via SQL Views, so therefore we will need a helper stored procedure to sort the output in a way the properly aggregates the EDI output.

First, launch Chiapas Studio and set up the Flat I/O Data Source window to connect to the chiapasData database (in most cases, the default connection string will be fine), and then ‘Table’ should be set to:

EXEC USP_ORDEREDI ‘vw_Export_834’

Then, press Execute, then select the HKey -> Flat to HKey pull down menu option, and press the Encode button. The EDI file will be displayed on the SegPool+Msgs pane. By pressing the Decode button, this same file will then be tested against HIPAA Level 1 and 2 SNIP integrity rules. In the first iteration, no error messages will be generated because the file will be a ‘clean’ EDI file from mock data.

Next, you will need to adjust the source code within the Stored Procedure to start projecting your business data instead of the included mock data and default values. Usually, this is best done just a few columns at a time before doing another cycle of testing within Chiapas Studio. You will have to select Help -> Reset All between test cycles to clear the internal Chiapas EDI registers.

It is very important to set at least one mapping for every header segment within every loop of your output. Furthermore, if you’d like suppress outputting certain loops in certain situations, every mapping associated with that loop must be set to NULL in order for the encoder engine to bypass that loop. Although the encoder can automatically populate HL and LX index values, the HL child code (HL04) must be supplied by the stored procedure.

When the resulting file successfully decodes without any errors and fulfills all of the business requirements, then the file can be said to be ‘ready’ for testing with the external trading partner.

How does Chiapas EDI 2014 enforce HIPAA compliant encryption?

No software can do this – a business must adopt HIPAA compliant communications policies and strictly enforce them. Primarily, this means that all Protected Healthcare Information must be protected with encryption and certain legal and binding agreements must be maintained between trading partners. Chiapas EDI natively supports encrypted SecureFTP communications using the integrated WinSCP client for communication with SecureFTP servers.

What automation capabilities are present within the software package?

Chiapas EDI 2014 comes with a rich set of Workflow Foundation 4 activities that allow users to create maintainable business processes with a graphical user interface. These processes can execute any function present within the Chiapas Studio interface, as well send EMails, put or get files on a Secure FTP server, interact with a database, and more. These activities are bundled into ‘Workflows’. Workflows can be triggered on a set schedule, the results of a SQL query, or new files placed in a directory or on a remote server.

Can I handle multiple files within a loop in the Workflow?

Chiapas EDI 2014 is not geared to handle multiple files within a single workflow instance. A single workflow should execute, at most, one encode and one decode operation. This means you will be able to decode a single file, store it to a table, execute some ETL, and then generate a 999 Acknowledgment file and save that to a different file.  If instead you enumerate files within a directory and try to decode them within a loop, this will have unpredictable results because the internal architecture of Chiapas EDI only fully ‘resets’ itself when the workflow first begins to execute.

This is an intentional part of the architecture of Chiapas EDI 2014: because numerous external factors within the .NET environment could be the source of a potential memory leak, the best way to process multiple files is to process them individually via the automation system, which will launch a new system process for every file being handled. As Worker processes only exist to handle a single workflow execution, they are constantly being respawned by the background Chiapas Service, and this in turn ensures a reliable and stable execution environment that can be stable for years at a time.

How scalable is Chiapas EDI 2014? What are some problems that hindered large scale file processing, and how were they resolved?

We’ve had a number of clients take advantage of the ‘core unlocked’ licensing tiers of the product and then use this product on some fairly beefy servers, processing literally tens of thousands of files at a time. Here are some insights:

Server Setup

To fully maximize server resources, you would need 3.5 worker processes and 3.5GB of free RAM for each physical core on the server. So, on a single CPU server with 8 cores, 24 worker processes and 24 GB free of RAM would allow that server to process 24 files simultaneously.

SQL Server Resource Contention

One significant obstacle encountered when trying to decode large-scale batches of files to a single database table is that SQL Server needs some special handling in order to work effectively. For example, when thirty Worker processes are all trying to insert data into the same database table simultaneously, resource locking and SQL timeouts become serious issues.

The latest release of Chiapas EDI 2014 has some logic for resolving these issues on two of the built-in database decode pipelines. First, all data is loaded into SQL Server to a uniquely named temp table. This eliminates the table locking issue, as each worker process is inserting into a dedicated table.

Then, a background automation process calls on a stored procedure which shuttles the data within these temp tables to their correct destination. Because this procedure works serially on one table at a time, it also avoids any possible table locking or timeouts.