What is TransSend?

TransSend 5.5.n is AXIOM System's unique software application developed specifically for Health Plans engaged in HIPAA commerce.

In today's cost-conscious healthcare marketplace, TransSend will save you real dollars by significantly reducing your administrative costs, and increase providers' satisfaction with your Health Plan. By leveraging the investments you have already made towards transaction compliance, TransSend will enable you to increase the level of HIPAA commerce transacted between you and your trading partners through the deployment of a secure and cost effective web based solution which will integrate seamlessly into your current business processes and streamline everyone's workflow.

TransSend is a comprehensive configurable business application solution, not just a technical toolkit.

What will it do for Me?

TransSend simplifies HIPAA e-commerce and provides real time transactions through an integrated Web portal interface. After implementation, all of your providers can create and submit HIPAA-compliant transactions online, which are immediately routed to your Health Plan. And all transactions can be reviewed via easy-to-read, web-accessed reports. TransSend's administrative tools can be customized to meet the individual needs of each payer and provider.

TransSend builds on your existing HIPAA investment with a subscription-based, low initial investment solution that can be quickly deployed in a matter of days. It immediately provides cost savings while simultaneously improving customer service and satisfaction.

TransSend provides tracking, searching, and reporting for all of your Health Plan's HIPAA transactions. Regardless of whether providers created a request using TransSend, a clearinghouse, or through their own internal systems; their transactions, along with your responses, are all viewable via well-designed, business friendly search screens and web reports.

TransSend enables your provider trading partners to create compliant transactions, including claim transactions. Often, the most basic obstacle a Health Plan faces is that many of their providers and clearinghouses cannot consistently and easily create fully-compliant 837s. TransSend's claim creation component fits seamlessly into your provider's existing workflow, does not require re-keying of claims, and is guaranteed to produce compliant claims that can be instantly delivered to you. The claim component will also accept a number of standard input file formats, including print files. It then processes them through a comprehensive set of data and compliance validation routines. The provider is notified when the source data is questionable or in error. Compliant files are transmitted automatically, while files with errors never leave the provider's office. If your provider has been generating paper claims or using a clearinghouse, it's a win-win for both of you.

How does it work?

TransSend high level Modules, Process Overviews and Other Capabilities, and Features and Facts are summarized below. Click on the link for more information or continue reading.

Modules	Payer Processing
	Workflow
	Provider Portal
	Payer Portal
	Real Time Transactions
	Encounter Processing
	Claims Creation
Process Overviews	General
	Inbound Claim Transactions (837)
	Outbound Claims (837)
	Inbound Enrollment (834 and proprietary)
	Inbound 820
	Outbound 820
	270/271
	276/277
	278 Request/Response
	835
	277CA
Other Capabilities, Features and Facts	4010/5010 Dual Processing
	HIPAA Compliance
	Code Set Updates
	Interfaces to Claims Adjudication Systems
	Interoperability
	Data Correction Capabilities
	Error Messaging
	Mapping and Customization Capabilities
	Trading Partner Management
	Transaction Balancing
	Logging and Auditing
	Technical and Operating Environment
	Daily Maintenance and Operation
	Software Updates
	Database Repository
Sample Screen Shots	See Below or Click Link

Modules

In order to simplify the description of some rather complex and interrelated functional components of TransSend, AXIOM categorized the application by Module.

Payer Processing - Inbound 837, 834, 820

Payer Processing refers to the components that allow Health Plans to receive, view, store, edit, perform business logic, and ultimately export inbound 837, 834 and 820 transactions to a back-end application. It also includes the ability to create outbound 835 transactions and includes a Payer EDI portal.

• Cross walk code sets
• Data updates
• Edits and validates business rules
• Provides batch management
• Supports transaction change audits
• Allows for user exception processing

Workflow

Workflow includes all of the functions required to support the exchange of HIPAA EDI transactions between trading partners, including compliance checking and acknowledgement generation.

• Manages file transfer and archival
• Compliance checking using a leading vendor
• Security and Logging
• Customizable flows
• Secure HIPAA EDI file transmission
• Messaging, communication, routing, and the management of the processes which control the flow of data between external trading partners and the enterprise, as well as within an enterprise, is critical to the successful implementation of a HIPAA Solution.
• Complete PGP Encryption and Decryption solution including key management capability and web based control of Inputs and Outputs is available.

Provider Portal

The Provider portal is similar to the Payer Portal but allows the application to lock down transaction level security to a Provider Entity, and allows for the secure browser based file transmission and download and allows Providers to generate real time request transactions (270/276/278) that are submitted to the Health Plan. Responses are immediately viewable in the Provider Portal. If you are using TransSend's Real Time Response Module, we simply drop the response into the Portal. Alternately, real time requests can be routed to your own EDI e-commerce infrastructure and the response transactions are dropped off into the TransSend data repository where they are immediately viewable by Providers as browser based screens and business documents.

• Security and ease of setup
• Web Services
• File Transfer

Real Time Transactions (27x)

TransSend's Real Time Transaction Module supports various methods that allow a Health Plan to receive compliant requests (270/276/278) and generate compliant responses. TransSend supports both real time (HTTPS based) or batch requests.

• Custom lookup processes
• Web Services
• 27x series transaction support
• Batch options

Encounter Processing

The TransSend Outbound Encounter Portal (TOPS) assists Medicare Advantage Organizations and Medicaid Organizations with submitting and reconciling accurate encounter data to the CMS Encounter Data Processing System (EDPS) and other state agencies. The TransSend Encounter Portal ensures that HIPAA compliant and clean files are sent and that standard, transparent, and measurable processes are adhered to, in order to deliver efficiencies in the overall transaction workflow.

The application is a web-based application that stores and transforms healthcare transactions (EDI) between Payers and their trading partners into easily viewable and understandable formats.

Encounter Processing and Reconciliation Features include:

• Identify HIPAA Compliance errors before encounters are sent to the receiving entity
• Identify errors (business edits) before they are sent to the entity
• Identify possible duplicate encounters which have been sent previously
• Ensures that resubmitted encounters are correctly identified
• Send only good transactions to the receiving entity
• Report successful receipt of the file by the receiving entity (997/999)
• Perform transaction level matching utilizing response claim status acknowledgements (277CA)
• Perform transaction level matching (Adjudication) of proprietary business edits from CMS and Medicaid to identify errors which need to be corrected.
• Track the status of each file and individual claim.
• Provide users the opportunity to annotate and then report on those claims which need to be corrected in either the adjudication systems for resubmission or the EDI creation process.
• Creates Reports on the percentage of acceptance of submissions providing transparency of the overall process and financial and operational metrics.
• Provides management level process overview information

Claims Creation

The TransSend Claims creation software allows a Health Plan to make available a browser based claims keying application. The application GUI resembles the standard CMS and UB forms that providers are used to working with. All edits are performed on the Provider's desktop and the application generates clean inbound 837 documents for the Health Plan. The same application accepts various input file formats (print files, nfs, 837) and runs through the same exact edits that would have occurred if the provider had keyed the claim directly. Think about this as the exact same process that a clearinghouse would perform to allow non-compliant providers to generate compliant transactions.

• Web based
• DDE (OEM vendor) or file based
• Clean claims business edits and compliance edits

Process Overviews

AXIOM's TransSend application provides the capability to accept and respond to all mandated Health Plan HIPAA Transactions and supports the ability to generate standard acknowledgements, including the 277CA, 997, 999, and TA1 transactions. Each inbound transaction is processed by a 'workflow' component that manages all front-end processes, including trading partner validation, customizable HIPAA Compliance checking, archiving, error reporting, removal of non-compliant transactions from an inbound file, and many other functions, before handing the file off to our proprietary TransSend EDI loader. The loader writes each transaction (including all data elements) into the application database, where they are immediately available for searching and viewing via standard customizable browser screens, and standard soap based web services.

Claim transactions (837), Enrollment transactions (834), and 820 transactions are supported by a distinct Payer Processing Module that allows Health Plan staff to monitor the status of batches of transactions, work individual exceptions (if configured), view original submitted EDI browser based business reports, and view modified data via browser based business reports. Original EDI data is never modified, all processing occurs in the corresponding payer processing module's staging tables.

Inbound Claim Transactions

Inbound Claim transactions are moved from the EDI database into the Payer Processing Module Staging tables. The Payer Processing Module assigns transactions to logical groupings called 'Organizations', which allows TransSend to apply specific business rules that are configured utilizing a browser based Boolean rules construction engine including:

• Member validation rules
• Claim splitting rules
• Cross walking rules
• Data trapping rules
• Network assignment rules

These rules can be associated with actions that can trigger automated update processes or that allow users to intervene to investigate and resolve exceptions. For instance, a series of member validation rules can be invoked to determine if a claim has a unique member match based on a number of full and partial key look-ups such as 1st 7 characters of member id, 1st 4 characters of last name, 1st character of first name, member DOB, etc. If an exact unique match is found, the claim is sent to the back-end system(s) in the Client specified output format(s), corrected with the Health Plan identifiers and member demographic data. If no match is found, the claim can be auto denied on an 835 transaction. If more than one match is found, the transaction can be halted and presented to a user allowing them to do a simple search and pick function to pick the unique member, or failing that, to manually deny the claim on a standard 835 transaction. In many cases, halted claims can be automatically reprocessed if the original halt reason is resolved. For instance, if a provider was not on file, but was added the next day, the claim can be configured to automatically be flagged as ready to extract.

Outbound Claims

Various outbound claim capabilities are supported. Generally speaking, TransSend has the ability to generate an outbound claim;

• For inbound claims that need to be routed to a re-pricer or other business associates
• As a re-priced claim if a supported application component is implemented
• As a secondary claim if a 835 has been processed or received
• As a reporting/encounter claim if an application component is implemented

AXIOM will customize each outbound claim process to ensure that trading partner requirements are met. For instance, specifying certain default values for encounter reporting, and specifying Sender and Receiver ISA/GS settings.

Outbound claims are compliance checked before being delivered for distribution, are viewable at the batch and transaction level, and can be configured to require and track specified acknowledgements and trigger exception reports if not received in a timely fashion.

In order to generate an outbound claim, a Client must have loaded an inbound claim. TransSend includes other application components that can generate 837P and 837I transactions from print files and other proprietary file formats. These are generally utilized by Provider Organizations, but have been successfully implemented for Payer to Payer claims as well.

Inbound 834

Inbound 834 transactions are conceptually managed in a similar fashion to inbound 837 transactions. Rather than run through the Claim Payer Processing module, inbound enrollment transactions run through the Enrollment Payer Processing Module.

Some key application features include:

• The addition of a separate data integrity step that allows the Health Plan to set targets based on number of transactions that are adds, terms, or changes, to allow early detection of potential trading partner submission problems.
• Additional data integrity rules can be set up to check for invalid or inconsistent data. This is useful for proprietary enrollment files where the file may not have been run through compliance checking.
• Halt actions on an inbound 834 can be configured to manually fix data or to skip transactions. If subsequent transactions are received for a member, they will back up and skip behind earlier transactions for that member and if the original halt reason is resolved, any subsequently skipped transactions can be automatically processed.
• Ability to compare full file replacements against an internal database of the Health Plan enrollment to determine if a member is added, changed, or terminated by absence.
• Ability to load proprietary enrollment files and allow them to run through the same or similar integrity and validation rules.
• Ability to Add/Change/Term enrollment data by creating 834 transactions within TransSend. These transactions flow through the same validation rules as other inbound 834 transactions would, and a proprietary load file is created for the Health Plan.

As with the 837 transactions, the customized rules can be applied by 'Organization'. In this case the organizations typically reflect an employer group or a submitter.

Outbound 834

TransSend supports the ability to generate outbound 834 full file transmissions. TransSend utilizes the same database tables that support our 271 creation and claim member validation, and inbound 834 comparison processes, to generate outbound 834 transactions.

Inbound 820

Similar to the 837 and 834 transactions, TransSend supports the ability to receive batches of 820 transactions, search and view the transactions individually or from a file level, and export the transactions in a standard output format that can be customized for each Health Plan.

Inbound 820 transactions are processed by the 820 Payer Processing Module. At the current time, TransSend does not contain any Inbound 820 Validation routines, however, the architecture is in place to implement functionality similar to what is available for inbound 837 and 834 transactions with minimal effort.

Outbound 820

TransSend supports the ability to generate outbound 820 file transmissions. TransSend includes a flat file load process that accepts data from Health Plans and loads the data to an internal database table, which is then utilized to generate outbound 820 transactions.

270/271

TransSend supports the ability to receive 270 transactions and generate 271 responses. TransSend provides a flat file load process that supports header level and benefit level (including limitations) data. These tables are utilized to generate 271 responses and to support Claim Member validation routines and inbound 834 comparison logic. TransSend applies various search criteria, utilizing 270 patient identifier and demographic information, to determine if a member is eligible. If the Health Plan is sending benefit and limitation information as a flat file, TransSend utilizes that information to generate a detailed 271 response. An alternate approach for Health Plans to provide real time current limitation information is to utilize TransSend's '270 Benefit Inquiry web service.' This web service invokes a Health Plan's web service, either before or after applying search criteria, against internal TransSend tables and after determining that a member is 'eligible'. The Health Plan web service response provides the benefit level and limitation information utilized in a detailed 271 response.

TransSend supports real time submission (single requests) and response to 270/271 requests via a web service architected to meet the CAQH Core II Real Time Request/Response guidelines. This enables Health Plan trading partners to update source systems in real time rather than through batch processes.

276/277

TransSend supports the ability to receive 276 transactions and generate 277 responses. TransSend provides a flat file load process that updates internal TransSend tables with claim processing information. TransSend performs the required search criteria against these tables and generates response transactions.

278 Request/Response

TransSend supports the ability to receive 278 requests and generate 278 responses. TransSend produces a standard format 278 request output file and provides a standard format input file format for responses. Alternately, requests can be converted to a standard supported web service call, and responses can be received utilizing a standard supported web service to generate an outbound 278 response.

835

TransSend generates compliant balanced 835 transactions. In order to produce a truly compliant 835, TransSend should have received an original 837 transaction or an 837 'like' transaction in order to ensure proper balancing of the 835, and in order to correctly reference the original submitted lines, procedure codes, modifiers, and charge amounts for the claim. The TransSend application provides a standard flat file input file format for receipt of Check, Claim, and Service Detail adjudication results. Generally, AXIOM takes any available formats and creates intermediate load tables assuming that the data meets minimum content requirements. The TransSend application performs an initial process against these remit files by first running a series of balancing and data integrity checks, applying configured business rules, and performing any initial custom code set cross walking that may be required. Once the data in the file has been validated and prepared, TransSend then locates the associated claims (837) utilizing sophisticated configurable matching rules. Once target claims are identified, TransSend performs a build-out process that begins to create 835's that correctly reflect claims splits, bundling and unbundling procedures, procedure and modifier replacements, prior partial payments as reflected in prior 835s, and a variety of other 835 specific use-case logic to correctly build a compliant 835 in the TransSend application db. The original data, the claims data, the build data, and the final 835 data are available to be viewed and are all linked in the 835 payer processing module, and the results update the payer and provider processing portal application so that users can easily view original claim submissions and the related 835 on-line.

Generally, TransSend Clients generate 835 transactions within the application framework for all claim payments (whether a trading partner wishes to receive a corresponding 835 EDI response or not) and configures the 835 module to only produce 835 EDI documents for submitters that wish to receive a compliant EDI response.

In addition to being able to generate an 835 based on back-end adjudication system results, TransSend can also generate 835's on the front-end for claim rejects (denials) that have been configured in the 837 Payer Processing validation engine. For instance, Clients can reject a claim on an 835 if the member cannot be identified. This avoids having to enter those claims in the Client adjudication system.

277CA

TransSend supports the capability to generate these transactions.

Other Capabilities

4010/5010 Dual Processing

TransSend supports dual processing of the 4010 and 5010 HIPAA Transactions.

Each mandated transaction requires specific application behavior changes. For instance, the new 270 search logic and subscriber definition changes requires a different configured search criteria, whereas the response requirements related to these changes have required a different 271 EDI transform.

TransSend's initial 5010 release was released on April 30, 2010. That release allowed all inbound and outbound transactions to be loaded into the EDI repository and the creation of browser based EDI transaction reports, search features, and the creation of 5010 Real Time Transaction Inquiries from the Provider Portal. Our second 5010 release was on October 31, 2010 and included all of the remaining 5010 related logic and functional changes.

HIPAA Compliance

All inbound and outbound transactions conform to the HIPAA X12 implementation guides and TR3 for supported transactions. The ability to produce compliant outbound transactions is somewhat dependent of the data quality of the Client's applications and adjudication systems; however, all outbound transactions can be run through the In-Stream compliance checker. Inbound transactions similarly run through the compliance checker. Edits can be relaxed by trading partner.

Code Set Updates

AXIOM advises Clients immediately when code sets change and provides Clients with an analysis of the changes. Upon advice from Client, AXIOM updates code sets in test environments and coordinates with Clients to migrate those changes to their production environments.

Interfaces to Claims Adjudication Systems

AXIOM will map to Client internal formats as part of the TransSend implementation services for each inbound payer processing transaction (837I, 837P, 837D, 834, 820). Alternately, each of the inbound payer processing modules produces a TransSend standard output file format that a Client can map from.

Interoperability

TransSend operates on a MicroSoft.net 3.5 framework and provides all interoperability capabilities fully supported by that environment, including support for standard SOAP-based web services and supported adaptors. Most basic file loading activities are asynchronous; however, supported web services can be synchronous or asynchronous. TransSend provides a web services interface capability to meet the needs of external access.

Data Correction Capabilities

Business validation rules include the ability to automatically update data, or based on configuration decisions made during implementation, to manually update specified field values. A comprehensive suite of validation, edit, and correction routines have been developed specifically to support cleansing 837 transactions that were created from scanned and OCRed claims.

Error Messaging

TransSend supports the generation of standard EDI error notifications (TA1, 997, 999, 277CA, 277U). In addition, HTTP connectivity and supported web service responses provide additional error message notification capabilities. Also, TransSend can be configured to generate email notification on certain failures and to produce custom messages and reports.

Mapping and Customization Capabilities

The TransSend product is not a general purpose mapping tool, however, various map-like features are configured utilizing browser based configuration screens to meet the needs of the X12 data exchange. In addition, transaction detail can be inspected utilizing GUI based screens and all export formats are supported by a mapping utility that specifies certain output masks and formatting instructions.

Trading Partner Management

TransSend allows organizations to specify routing rules for trading partners globally or based on specific transaction, and transaction versions such that a trading partner who is not certified to send a 5010 837, for example, would not be able to route that transaction into a production environment. Instead, the transaction can be routed to a test environment or rejected with appropriate notifications.

Transaction Balancing

TransSend provides file and transaction level reconciliation capabilities to transmitting trading partners in the form of standard transaction level acknowledgements (277CA, 277CU) for claim transactions, and provides the ability to generate custom transaction control reports that can be viewed via a browser or transmitted via email for claims and other batch transmissions (834, 270,276). Additionally, TransSend validates the receipt and processing of inbound transactions that are submitted into the back-end application.

For claim transactions, TransSend prefers to receive an update to a set of tables that link TransSend claims to Client claims. Failing this, TransSend has the ability to reconcile nightly claim loads (support for 276/277) and 835 remit files to transactions that have been exported. For each request/response pair (276/277, 270/271, 278/278) that is sent to a back-end, TransSend maintains a record ID that is used for balancing and reconciliation.

All batch level information is logged upon first receipt by the workflow engine and copies of files are made each time an action is taken on a file, before being loaded into the application. This allows for auditing and recoverability in the event of an error (for instance, if a password protected zipped file is received and the unzipping fails for an undetermined reason, the original unzipped file is retained and an error is generated on the unzip event).

Logging and Auditing

TransSend supports auditing and maintains log tables that capture before and after field values for any data updated by the payer processing modules. Logs are maintained and reports can be generated to support performance metrics. Also db logging can be turned on.

Technical and Operating Environment

SOFTWARE

Windows 2008 Enterprise Edition x64 w/ SP2 or above (Latest patches)

SQL Server 2005 Enterprise Edition x64 w/ SP3 or higher and latest patches

Microsoft.Net Framework 3.5 SP1

Microsoft.Net Framework 1.1

Daily Maintenance and Operation

Once configured and implemented, the TransSend application requires minimal support to operate.

The skill set of individuals responsible for the daily maintenance and operation of the TransSend product at the client location would include:

• Basic understanding of EDI processing.
• Understanding of the business processing rules.
• Understanding of workflow and trading partner management.
• Standard IT maintenance functions for any Microsoft based environment, DBA, Back-ups, etc.

Software Updates

AXIOM provides updates to its software on a quarterly basis and requires that Clients migrate to new releases on a semi-annual basis.

Database Repository

Every data element of every EDI transaction is stored in the EDI repository. Data is searchable via browser based search screens, and transaction detailed reports can be invoked via supported soap based web service requests.

Sample Screen Shots