Tuesday, April 29, 2008

Trasaction in Java (JTA)

Explain the different Transaction Attributes and Isolation Levels with reference to a scenario ?

Answer
The Enterprise JavaBeans model supports six different transaction rules:

  • TX_BEAN_MANAGED. The TX_BEAN_MANAGED setting indicates that the enterprise bean manually manages its own transaction control. EJB supports manual transaction demarcation using the Java Transaction API. This is very tricky and should not be attempted without a really good reason.
  • TX_NOT_SUPPORTED. The TX_NOT_SUPPORTED setting indicates that the enterprise bean cannot execute within the context of a transaction. If a client (i.e., whatever called the method-either a remote client or another enterprise bean) has a transaction when it calls the enterprise bean, the container suspends the transaction for the duration of the method call.
  • TX_SUPPORTS. The TX_SUPPORTS setting indicates that the enterprise bean can run with or without a transaction context. If a client has a transaction when it calls the enterprise bean, the method will join the client's transaction context. If the client does not have a transaction, the method will run without a transaction.
  • TX_REQUIRED. The TX_REQUIRED setting indicates that the enterprise bean must execute within the context of a transaction. If a client has a transaction when it calls the enterprise bean, the method will join the client's transaction context. If the client does not have a transaction, the container automatically starts a new transaction for the method. Attributes
  • TX_REQUIRES_NEW. The TX_REQUIRES_NEW setting indicates that the enterprise bean must execute within the context of a new transaction. The container always starts a new transaction for the method. If the client has a transaction when it calls the enterprise bean, the container suspends the client's transaction for the duration of the method call.
  • TX_MANDATORY. The TX_MANDATORY setting indicates that the enterprise bean must always execute within the context of the client's transaction. If the client does not have a transaction when it calls the enterprise bean, the container throws the TransactionRequired exception and the request fails.

Transaction Management

1. Which transaction attributes should I use in which situations?

2. How can I handle transaction isolation?

3. Does the J2EE platform support distributed transactions?

4. Does the J2EE platform support nested transactions?

5. What are some tips for using bean-managed transaction demarcation?

6. What are some tips for using container-managed transaction demarcation?

7. Can an entity bean use bean-managed transaction demarcation?

8. Should I put a transactional attribute on an asynchronous action such as sending an email?

9. Can I use multiple connections to the same resource manager from within a bean instance that executes in an XA or a global transaction ?

1. Which transaction attributes should I use in which situations?

The following are some of the points to be remembered when specifying transaction attributes for Enterprise JavaBeansTM-technology based components (EJBTM):

* All methods of a session bean's remote interface (and super interfaces) must have specified transaction attributes.

* Session bean home interface methods should not have transaction attributes.

* (All methods of an entity bean's remote and home interfaces (and super interfaces) must have specified transaction attributes, with the exception of: methods getEJBHome(), getHandle(), getPrimaryKey(), isIdentical() methods of the remote interface; and methods getEJBMetaData(), getHomeHandle() of the home interface.

* Use Required as the default transaction attribute, to ensure that methods are invoked within a Java Transaction API (JTA) transaction context. Required causes the enterprise bean to use existing transactional context if it exists, or to create one otherwise.

* Use RequiresNew when the results of the method must be committed regardless whether the caller's transaction succeeds. For example, a method that logs all attempted transactions, whether those transaction succeed or not, could use RequiresNew to add log entries. RequiresNew always creates a new transaction context before the method call, and commits or rolls back after the method call. Note that any existing client transaction context will be suspended until the method call returns.

* Use Supports for methods that either do not change the database (directly or indirectly); or update atomically, and it does not matter whether or not the update occurs within a transaction. Supports uses the client transaction context if it exists, or no transaction context otherwise.

* Use Mandatory when the method absolutely requires an existing transaction. Mandatory causes RemoteException to be thrown unless the client is associated with a transaction context.

* Use Never to ensure that a transactional client does not access methods that are not capable of participating in the transaction. Never causes RemoteException to be thrown if the client is associated with a transactional context.

* Use NotSupported when an enterprise bean accesses a resource manager that either does not support external transaction coordination, or is not supported by the J2EE product. In this case, the bean must have container-managed transaction demarcation, and all its methods must be marked NotSupported. NotSupported will result in the method being called outside of any transaction context, whether or not one exists.

* Enterprise beans that implement interface SessionSynchronization must have either the Required, RequiresNew, or Mandatory transaction attribute.

2. How can I handle transaction isolation?

The EJB specification indicates that the API for controlling transaction isolation level is specific to the resource manager implementation, and therefore the architecture does not define and isolation level control API.

If a container uses only one bean instance per primary key, the container will synchronize access to the bean and therefore transaction isolation is unnecessary. Containers that use multiple instances per primary key depend on the underlying database for isolation.

Enterprise beans using container-managed persistence use the default isolation level of the underlying database; therefore, the isolation level cannot modified. Entity beans using bean-managed persistence may use the underlying DBMS API to change the isolation level (using, for example, Connection.setTransactionIsolation().)

3. Does the J2EE platform support distributed transactions?

Yes, the J2EE platform allows multiple databases to participate in a transaction. These databases may be spread across multiple machines, using multiple EJB technology-enabled servers from multiple vendors.

4. Does the J2EE platform support nested transactions?

No, the J2EE platform supports only flat transactions.

5. What are some tips for using bean-managed transaction demarcation?

* Session beans should use bean-managed transaction demarcation, although can use container-managed demarcation. Entity beans must use container-managed demarcation.

* An enterprise bean should not invoke resource manager-specific transition demarcation API methods (like java.sql.Connection.commit(), java.sql.Connection.rollback(), etc.) while within a transaction.

* Stateless session beans should always either commit or rollback a transaction before the business method returns. Stateful session beans do not have this requirement. Instead of calling EJBContext.getRollBackOnly(), and javax.ejb.EJBContext.setRollbackOnly(), use the corresponding JTA API calls.

6. What are some tips for using container-managed transaction demarcation?

* Do not invoke a resource-manager-specific transaction demarcation API (like Connection.commit(), and so on).

* Avoid using interface UserTransaction.

* Implement rollbacks by calling EJBContext, and then throwing an exception.

7. Can an entity bean use bean-managed transaction demarcation?

No. Entity beans always use container-managed transaction demarcation. Session beans can use either container-managed or bean-managed transaction demarcation, but not at the same time.

8. Should I put a transactional attribute on an asynchronous action such as sending an email?

No. Simply putting a transactional attribute on a method won't help if the resource manager can't use a transactional context.

9. Can I use multiple connections to the same resource manager from within a bean instance that executes in an XA or a global transaction ?

A bean instance that executes in an XA or a global transaction should not use multiple connections to the same resource manager.

Specifically, a bean instance that executes in an XA transaction should not cache more than one connection to the same resource manager. Further, it should not create more than one connection to the same resource manager from within a bean method under a single XA transaction.

This is needed because even though XA allows multiple connections to be enlisted in a single transaction branch, there are some restrictions. Some resource managers do not allow more than one connection to be simultaneously enlisted in the same transaction branch.

Note however that within a single XA transaction, there can be more than one connection to a single resource manager, spread across different bean instances.

Friday, April 25, 2008

HIPAA ,US Standards in Health Insurence

FAQs About Electronic Transaction Standards Adopted Under HIPAA



Questions


Answers

Why have national standards for electronic health care transactions been adopted and why are they required?

Congress and the health care industry have agreed that standards for the electronic exchange of administrative and financial health care transactions are needed to improve the efficiency and effectiveness of the health care system. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required the Secretary of Health and Human Services to adopt such standards.

National standards for electronic health care transactions will encourage electronic commerce in the health care industry and ultimately simplify the processes involved. This will result in savings from the reduction in administrative burdens on health care providers and health plans. Today, health care providers and health plans that conduct business electronically must use many different formats for electronic transactions. For example, about 400 different formats exist today for health care claims. With a national standard for electronic claims and other transactions, health care providers will be able to submit the same transaction to any health plan in the United States and the health plan must accept it. Health plans will be able to send standard electronic transactions such as remittance advices and referral authorizations to health care providers. These national standards will make electronic data interchange a viable and preferable alternative to paper processing for providers and health plans alike.

What health care transactions are required to use the standards under this regulation?

As required by HIPAA, the Secretary of Health and Human Services is adopting standards for the following administrative and financial health care transactions:

  1. Health claims and equivalent encounter information.
  2. Enrollment and disenrollment in a health plan.
  3. Eligibility for a health plan.
  4. Health care payment and remittance advice.
  5. Health plan premium payments.
  6. Health claim status.
  7. Referral certification and authorization.
  8. Coordination of benefits.

Standards for the first report of injury and claims attachments (also required by HIPAA) will be adopted at a later date.

Who is required to use the standards?

All private sector health plans (including managed care organizations and ERISA plans, but exlcuding certain small self administered health plans) and government health plans (including Medicare, State Medicaid programs, the Military Health System for active duty and civilian personnel, the Veterans Health Administration, and Indian Health Service programs), all health care clearinghouses, and all health care providers that choose to submit or receive these transactions electronically are required to use these standards. These "covered entities" must use the standards when conducting any of the defined transactions covered under the HIPAA.

A health care clearinghouse may accept nonstandard transactions for the sole purpose of translating them into standard transactions for sending customers and may accept standard transactions and translate them into nonstandard transactions for receiving customers.

If a health plan does not perform a transaction electronically, must it implement the standard?

If the plan performs that business function (whether electronically, on paper, via phone, etc.), it must be able to support the electronic standard for that transaction. It may do this directly or through a clearinghouse.

When will the standards become effective?

All health plans, all health care clearinghouses, and any health care provider that chooses to transmit any of the transactions in electronic form must comply within 24 months after the effective date of the final rule (small health plans have 36 months). The effective date of the rule is 2 months after publication. Therefore, compliance with the final rule is required by October 2002 (October 2003 for small health plans). Entities can begin using these standards earlier than the compliance date.

Where did these standards come from? Did the Federal Government create them?

HIPAA required the Secretary to adopt standards, when possible, that have been developed by private sector standards development organizations (SDOs) accredited by the American National Standards Institute (ANSI). These are not government agencies. All of the transactions adopted by this rule are from such organizations. All are from the Accredited Standards Committee (ASC) X12N except the standards for retail pharmacy transactions, which are from the National Council for Prescription Drug Programs (NCPDP).

What standards were chosen?

ANSI ASC X12N standards, Version 4010, were chosen for all of the transactions except retail pharmacy transactions. The choice for the retail pharmacy transactions was the standard maintained by the NCPDP because it is already in widespread use. The NCPDP Telecommunications Standard Format Version 5.1 and equivalent NCPDP Batch Standard Version 1.0 have been adopted in this rule (health plans will be required to support one of these two NCPDP formats).

Do these standards apply to transactions sent over the Internet?

Internet transactions are being treated the same as other electronic transactions. However, we recognize that there are certain transmission modes in which the format portion of the standard is inappropriate. In these cases, the transaction must conform to the data content portion of the standard. In particular, a "direct data entry" process, where the data are directly keyed by a health care provider into a health plan’s computer using dumb terminals or computer browser screens, would not have to use the format portion of the standard, but the data content must conform. If the data are directly entered into a system that is outside the health plan’s system, to be transmitted later to the health plan, the transaction must be sent using the format and content of the standard.

Do I have to use standard transactions when conducting business inside my corporate boundaries?

The decision on when a standard must be used does not depend on whether the transaction is being sent inside or outside corporate boundaries. Instead, a simple two part test, in question form, can be used to determine whether the standards are required.

Question 1: Is the transaction initiated by a covered entity or its business associate? If no, the standard need not be used.

Question 2: Is the transaction one for which the Secretary had adopted a standard? If yes, the standard must be used. If no, the standard need not be used.

For purposes of question 1, a business associate acting on behalf of a covered entity can only perform those particular functions that the covered entity itself could perform in the transaction. The regulation requires health plans to accept standard transactions from any person.

For purposed of question 2, the definitions of the transactions themselves, as stipulated in Subpart K through Subpart R of the regulation, must be used to determine if the function is a transaction for which the Secretary has adopted a standard.

What is the effect on State law?

Section 1178 of the Social Security Act provides that standards for the transactions will supercede any State law that is contrary to them, but allows for an exception process. This process is currently under development and will be issued in the final rule for Privacy Standards.

Are any exceptions allowed?

In addition to the exceptions for conflicting State laws, an exception may be allowed for the testing of proposed modifications to the standards. An entity wishing to test a different standard may apply for an exception to test the new standard. Instructions for applications are published in the final rule. In this way, we hope to encourage the development of new technologies.

What does the law require of state Medicaid programs?

Section 1171(5)(E) of the Social Security Act, as enacted by HIPAA, identifies the State Medicaid programs as health plans, which therefore must be capable of receiving, processing, and sending standard transactions electronically. There is no requirement that internal information systems maintain data in accordance with the standards. However, Medicaid programs will need the capacity to process standard claim, encounter, enrollment, eligibility, remittance advice, and other transactions. In addition, as health plans, the State Medicaid programs will be required to comply with other HIPAA standards two years after adoption of the standards.

The standards should benefit Medicaid programs in multiple areas. Here are a few examples:

  • A national standard for encounter transactions will provide a much-needed method for collecting encounter data on Medicaid beneficiaries enrolled in managed care. Because of the standards, it will be possible to combine encounter data from managed care with similar claims data from fee-for-service, thus enhancing the ability to monitor utilization, costs, and quality of care in managed care and to compare managed care with fee-for-service.
  • The standard transactions will include methods for electronic exchange of enrollment information between the Medicaid program and private managed care plans enrolling Medicaid beneficiaries. This will reduce administrative costs of exchanging such information and enhance the reliability of such information.
  • The conversion to national standards provides an opportunity for Medicaid programs to shift to commercial software or clearinghouses and to stop the expensive maintenance of old, customized transaction systems.

How will the standards be enforced?

The law gives the Secretary the authority to impose monetary penalties for failure to comply with a standard. The Secretary is required by statute to impose penalties of not more than $100 per violation on any person or entity who fails to comply with a standard except that the total amount imposed on any one person in each calendar year may not exceed $25,000 for violations of one requirement. Enforcement procedures will be published in a future regulation.

How were the standards chosen?

First, the Department developed a set of guiding principles to serve as the basis for evaluating alternative standards for each transaction. These guiding principles, designed to be consistent with the intent of HIPAA, are published in the regulation. Second, an inventory of standards was developed by the ANSI Health Informatics Standards Board, a private sector organization. Third, teams composed of representatives from several government agencies evaluated the available standards against the guiding principles to determine which standards best met the principles. Extensive outreach and consultation, including public meetings, with all facets of the health care industry continued throughout this process.

As required by HIPAA, the Secretary also consulted with the National Uniform Claim Committee (NUCC), the National Uniform Billing Committee (NUBC), the American Dental Association (ADA), and the Workgroup for Electronic Data Interchange (WEDI). The Secretary also considered advice from the National Committee on Vital and Health Statistics (NCVHS) and representatives of the health care industry who testified before the NCVHS Subcommittee on Health Data Needs, Standards, and Security.

Data dictionaries are available for an additional fee.

Where can I obtain implementation guides for the standards?

The implementation guides for the ASC X12N standards may be obtained from the Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone: 301-949-9740; FAX: 301-949-9742. These guides are also available at no cost through the Washington Publishing Company on the Internet at http://www.wpc-edi.com/hipaa/.

The implementation guide for retail pharmacy standards is available from the National Council for Prescription Drug Programs, 4201 North 24th Street, Suite 365, Phoenix, AZ, 85016; telephone: 602-957-9105; FAX: 602-955-0749. It is also available from the NCPDP’s website at http://www.ncpdp.org.

How can the standards be changed?

The Secretary has designated six organizations that have agreed to serve as Designated Standards Maintenance Organizations (DSMOs). The DSMOs are:

  1. Accredited Standards Committee X12
  2. The Dental Content Committee
  3. Health Level Seven
  4. National Council for Prescription Drug Programs
  5. National Uniform Billing Committee
  6. National Uniform Claim Committee

These organizations will work together to accept and evaluate requests for changes to the standards and suggest changes to the standards for the Secretary’s consideration. Further information about the change request process can be found on the Internet at: http://www.hipaa-dsmo.org .

The Secretary may modify a standard or its implementation guide specification one year after the standard or implementation specification has been adopted, but not more frequently than once every 12 months. If the Secretary modifies a standard or implementation specification, the implementation date of the modified standard or implementation specification may be no earlier than 180 days following the adoption of the modification. The Department of Health and Human Services (HHS) will determine the actual date, taking into account the time needed to comply given the nature and extent of the modification. HHS may extend the time for compliance for small health plans. Standards modifications will be published as regulations in the Federal Register.

Does the law require physicians to buy computers?

No, there is no such requirement. However, more physicians may want to use computers for submitting and receiving transactions (such as health care claims and remittances/payments) electronically, once the standard way of doing things goes into effect.

The Administrative Simplification provisions of the HIPAA law were passed with the support of the health care industry. The industry believed standards would lower the cost and administrative burdens of health care, but they needed Government's help to get to one uniform way of doing things. In the past, individual providers (physicians and others) have had to submit transactions in whatever form each health plan required. Health plans could not agree on a standard without giving their competitors a market advantage, at least in the short-run. The law, which requires standards to be followed for electronic transmission of health care transactions, levels the playing field. It does not require providers to submit transactions electronically. It does require that all transactions submitted electronically comply with the standards.

Providers, even those without computers, may want to adopt these standard electronic transactions, so they can benefit directly from the reductions in cost and burden. This is possible because the law allows providers (and health plans too, for that matter) to contract with clearinghouses to conduct the standard electronic transactions for them.

How will the standards affect data stored in my system?

The transaction standards will apply only to electronic data interchange (EDI) -- when data are transmitted electronically between health care providers and health plans as part of a standard transaction. Data may be stored in any format as long as it can be translated into the standard transaction when required. Security standards, on the other hand, will apply to all health care information.

To comply with the transaction standards, health care providers and health plans may exchange the standard transactions directly, or they may contract with a clearinghouse to perform this function. Clearinghouses may receive non-standard transactions from a provider, but they must convert these into standard transactions for submission to the health plan. Similarly, if a health plan contracts with a clearinghouse, the health plan may submit non-standard transactions to the clearinghouse, but the clearinghouse must convert these into standard transactions for submission to the provider.

Can health plans require changes or additions to the standard claim?

Currently, some insurers accept the de facto standard claim (e.g., UB-92) but also require additional records (e.g., a proprietary cover sheet) for each claim submitted. Others have special requirements for data entered into the claim which make it non-standard.

Under the law, health plans are required to accept the standard claim submitted electronically. They may not require providers to make changes or additions to the standard claim. They must go through the private sector standards setting process to get their requirements added to the standard in order to effect desired changes. Health plans may not refuse the standard transaction or delay payment of a proper standard transaction.

An additional standard will be adopted for electronic health claims attachments, which health plans will be required also to accept. Until that standard is adopted (by February, 2001), health plans may continue to require health claim attachments to be submitted on paper. No other additions to standard claims will be acceptable.

Should health plans publish companion documents that augment the information in the standard implementation guides for electronic transactions?

Additional information may be provided within certain limits.

Electronic transactions must go through two levels of scrutiny:

  1. Compliance with the HIPAA standard. The requirements for compliance must be completely described in the HIPAA implementation guides and may not be modified by the health plans or by the health care providers using the particular transaction.
  2. Specific processing or adjudication by the particular system reading or writing the standard transaction. Specific processing systems will vary from health plan to health plan, and additional information regarding the processing or adjudication policies of a particular health plan may be helpful to providers.

Such additional information may not be used to modify the standard and may not include:

  • Instructions to modify the definition, condition, or use of a data element or segment in the HIPAA standard implementation guide.
  • Requests for data elements or segments that are not stipulated in the HIPAA standard implementation guide.
  • Requests for codes or data values that are not valid based on the HIPAA standard implementation guide. Such codes or values could be invalid because they are marked not used in the implementation guide or because they are simply not mentioned in the guide.
  • Change the meaning or intent of a HIPAA standard implementation guide.

Could companion documents from health plans define cases where the health plan wants particular pieces of data used or not used?

The health plan must read and write HIPAA standard transactions exactly as they are described in the standard implementation guides. The only exception would be if the guide explicitly gives discretion regarding a data element to a health plan. For claims and most other transactions, the receiver must accept and process any transaction that meets the national standard. This is necessary because multiple health plans may be scheduled to receive a given transaction (e.g., a single claim may be processed by multiple health plans).

For example: Medicare currently instructs providers to bill for certain services only under certain circumstances. Once HIPAA standard transactions are implemented, Medicare will have to forego that policy and process all claims that meet HIPAA specifications. This does not mean that Medicare, or any other health plan, has to change payment policy. Today, Medicare would refuse to accept and process a bill for a face lift for cosmetic purposes only. Once the HIPAA standards are implemented, Medicare will be required to accept and process the bill, but still will not pay for a face lift that is purely for cosmetic purposes.

May health plans stipulate the codes or data values they are willing to accept and process in order to simplify implementation?

The simplest implementation is the one that is identical to all others. If the standard adopted stipulates that HCPCS codes will be used to describe procedures, then the health plan must abide by the instructions for the use of HCPCS codes. A health plan could refuse a code that was not applied in accordance with the HIPAA national standard coding instructions, but could not refuse a code properly applied for reasons of policy unrelated to the standard.

For example, if the standard stipulates that the most specific code available must be used, then a health plan would be right to refuse a code that does not meet that criterion. The health plan would need to work with the committee(s) governing the particular coding scheme to have codes adopted that meet its needs.

May health plans stipulate the number of loop iterations or the file sizes they are willing to accept?

Any loop iterations, file sizes, etc. stipulated in the standards must be honored by all players. If any health care electronic data interchange participant cannot live with the numbers stipulated in the HIPAA implementation guides, then the participant needs to work with the implementation guide author(s) to get numbers that all players can live with

For example, there are up to 99 service lines in a professional claim. The provider need not write 99 service lines, but the health plan must have the capability to accept that number when presented. If that is not the right number for all players, it should be changed. But the number identified in the implementation guide must be adhered to.


EDI In XML

HL7 ---health level 7

HL 7 messaging converted to xml

The Health Insurance Portability and Accountability Act of 1996 (HIPAA)

HIPAA standardize specific transaction numbers for transaction

1) Supporting Healthcare EDI Standards (X12 & HL7)

DataDirect XML Converters provide robust support for X12 electronic data interchange (EDI) and Health Level Seven (HL7) clinical and administrative healthcare data standards. Healthcare payers and providers use DataDirect XML Converters to help expedite the following scenarios and deliver timely and effective patient care:

§ Benefit enrollment and maintenance

§ Coverage eligibility and core authorizations

§ Claims submissions and status inquiries

§ Claims payment and notifications

§ Clinical care management

We’ve created two new tutorials to get you started quickly with these standards.

§ Converting from HL7 2.x to 3.x

§ Translating X12 documents to XML

2) Using XQuery with MySQL

Users with MySQL database deployments can now take advantage of all the benefits of DataDirect's XQuery engine. That means that finally MySQL users have access to a standard way (XQuery) to get access to their data as XML.

To see how all this works, and how MySQL users can take advantage of this opportunity, we have created a few examples on our web site; see how easy it is to use XQuery to:

§ Extract data from MySQL as XML

§ Aggregate it with XML documents or EDI documents

§ Update your MySQL data

3) XML-based Data Services Workshop

This spring we'll be bringing you Building Data Services Providing Access to Heterogeneous Data Sources – a workshop where we'll be writing, testing and deploying a solution for a typical data services scenario using XML and XQuery. The workshop covers:

§ Transforming XML documents into user-defined formats

§ Aggregating XML documents with relational data

§ Consuming Web services in XQuery

§ Exposing XQuery as data services

§ Integrating with non-XML B2B standards, like EDI

§ Adhering to XML industry standards, such as ACORD for insurance

Order Series (ORD )(810 invoice ,832sales,850PO,855PO ackaledge,

856 ship notice,

865 POchange ,

857 shipment notice,

880 gracery pruduct invoice ,

865 po change ,

881 Mfg coopen,881

Tax Services Series (TAX (from 150 ---

Materials Handling Series (MAT)511 requisition,517 merial validation,527 material due in and receipt ,843 req,res quotation

845 price status 847 material cliaims,851 asset schedule ,893 item info req

Tax Services Series (TAX)

149 notice on tax ,151,152 Statistical Government Information ,

155 business credit report ,

157notice to power attorney ,

170 Revenue Receipts Statement ,521

813 electonic filling of tax return data

826 Tax Information Exchange

Warehousing Series (WAR)

883 Market Development Fund Allocation,

884 Market Development Fund Settlement,

886 Customer Call Reporting ,

891 Deduction Research Report

945 Warehouse Shipping Advice

947 Warehouse Inventory Adjustment Advice

943 Warehouse Stock Transfer Shipment Advice

944 Warehouse Stock Transfer Receipt Advice

Financial Series (FIN)

810 invoice

248 account assignment

812 credit /debit adjustment

818 Commission Sales Report

819 Operating Expense Statement

820 PO

822 Account Analysis

821 Financial Information Reporting

859 Freight Invoice

823 Lockbox

824 Application Advice

827 Financial Return Notice

828 Debit Authorization

Government Series (GOV)

150 Tax Rate Notification

151 Electronic Filing of Tax Return Data Acknowledgment

152 152 Statistical Government Information

153 Uniform Commercial Code Filing

176 Court Submission

208 voter reg info

Manufacturing Series (MAN)

196,830,844

Delivery Series (DEL)

219,220,222 for logistics, 862 shipping schedule

882 direct store

Insurance/Health Series (INS)

100 Insurance Plan Description

112 Property Damage Report

148 Report of Injury, Illness or Incident

186 Insurance Underwriting Requirements Reporting

252 Insurance Producer Administration

252 Underwriting Information Services

268 Annuity Activity

267 Individual Life, Annuity and Disability Application

270 Eligibility, Coverage or Benefit Inquiry

274 Health Care Provider Information

272 Property and Casualty Loss Notification

273 Insurance/Annuity Application Status

276 Health Care Claim Status Request

275 Patient Information

837 Health Care Claim

288 Wage Determination

500 Medical Event Reporting

277 Health Care Claim Status Notification

820 Premium Payments

925 Claim Tracer

928 Automotive Inspection Detail

924 Loss or Damage Claim - Motor Vehicle

Miscellaneous ANSI X12 Transactions Series (MIS)

101 Name and Address Lists

997 Functional Acknowledgment

868 Electronic Form Structure

---------------------------------------------------

ASC X12

ASC X12 (also known as ANSI ASC X12) is the official designation of the U.S. national standards body for the development and maintenance of Electronic Data Interchange (EDI) standards. The group was founded in 1979, and is an accredited standards committee under the American National Standards Institute (ANSI). The acronym stands for "American National Standards Institute Accredited Standards Committee X12", with the designation of X12 being a sequential designator assigned by ANSI at the time of accreditation with no other significance.

ASC X12 has sponsored more than 315 X12-based EDI standards and a growing collection of X12 XML schemas for health care, insurance, government, transportation, finance, and many other industries. ASC X12's membership includes 3,000+ standards experts representing over 350 companies from multiple business domains.

HL7 Messaging System


With every passing day, the market pressure to be a "Real-time Enterprise" is building slowly but surely on the Healthcare Organizations (HCO). This is in addition to the governmental regulation compliance on patient privacy, decreased government reimbursement for the services provided and ever-presentcompetition in the healthcare markets to take away the market share of an HCO. With the access to the information becoming, "anytime, anywhere" via the internet, the patients will start expecting personalized real-time access to their health information to make better decisions about their health and healthcare purchases.

Our technology meet today's HCO challenges

To meet these challenges, an HCO has to be agile and nimble with the ability to respond quickly to the changes to improve the patient care while reducing the cost. This requires that the HCO's information systems be integrated to provide the right information to the right provider on time. Many of HCOs today use the industry standard Health Level 7 (HL7) and X12 messaging mechanism to exchange patient care information among various systems used in the organization.

Though HL7 is supposed to be an industry-standard, the variations and the customizations on the HL7 message definitions do not make the implementation of HL7 any easier. Combine that with HL7 version difference between different HCO's that need to share information about patient registration, admission, discharge, transfers, orders and results for laboratory tests, it does get very complicated rather quickly.

eTransX' HL7 messaging easy implementation solution

eTransX' HL7 messaging solution makes it easier to solve this problem. With a point-and-click data mapping and XML schema based HL7 messages with its guaranteed delivery on the HL7/X12 transactions, it takes the difficulties associated with customized HL7 messaging and version difference out of an HCO. It allows an HCO to implement a full-blown HL7 messaging system out-of-the-box, in a very short time with absolutely no programming. This reduces the cost and improves the information sharing which results in a better patient care for the HCO.