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
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.
||Real Time Transactions
||Inbound Claim Transactions (837)
||Outbound Claims (837)
||Inbound Enrollment (834 and proprietary)
|Other Capabilities, Features and Facts
||4010/5010 Dual Processing
||Code Set Updates
||Interfaces to Claims Adjudication Systems
||Data Correction Capabilities
||Mapping and Customization Capabilities
||Trading Partner Management
||Logging and Auditing
||Technical and Operating Environment
||Daily Maintenance and Operation
|Sample Screen Shots
||See Below or Click Link
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 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.
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
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
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
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
TransSend supports the capability to generate these transactions.
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.
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.
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.
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.
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
|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.
AXIOM provides updates to its software on a quarterly basis and requires that Clients migrate to new releases on a semi-annual basis.
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