java related technologies summary

Languages :
JDK1.7, C, C++, Java, Python, lisp, Ruby, COBOL, FORTRAN, Pascal, Fox pro, SQL, UML.
Web Technologies:
JDBC, Servlets, JSP, RMI, EJB, JNDI, Java Beans, JMS, Java Mail,LDAP,JDO, JPA , Java Doc,CORBA, MQ Series, JTA, JDO, POJO, JSTL, Struts Tag Libraries, i18N, Junit, easyMock.
Front End Technologies:
XHTML4, DHTML,JSP,Swing, JSF, AWT, ColdFusion, Perl, PHP, Struts 2.0, ASP, Visual Basic,
JavaScript--web 2.0,JSON, DOJO, Extj, GWT, YUI,EXT JS,JQuery,Prototype,Scriptaculous
DTM SQL editor , Html editor Dream Weaver, DOM.
ECM Tools:
EMC Documentum, Interwoven Team site ,IBM File Net , Vignette,IBM MAXIMO ASSET Mgt tool
DataBases ----- Oracle8i/9i/10g,oracle, IBM DB2, Sybase, exist, Tera Data, MS SQL Server, Sun MySQL, NCR Teradata, eXist, Sybase, IBM Informix 7, Cloudscape 4.0
Web/Application servers:
Weblogic 7.1/8.1/9.2/10,IBM Websphere5/6.1, Oracle Application Server10g, Tomcat4/5/6, JBoss4.2, Adobe JRun, Pramati Server 3.0, Orion app server (j2ee 1.3),Web logic portal 9.2/10 , BroadVision , JBoss portals
RDBMS tools : MS SQL Query Analyzer, Toad9.6 , Pl/sql Developer , apex sql edit, ERWin DB Model SQL Navigator , SQL Prompt , alotova sql editor, SQL Prompt , alotova sql editor, AquafoldSql editor
EAI Tools: ESB, TIBCO, Web Methods, JCAPS, IBM Process Server.
JAVA Rules Engines –PEGA, ISACS Blaze Advisor Rules Engine.
Frameworks: Jakarta Struts, Validator framework, spring, Web Services, SMC.
XML Technologies:
XML, XSD, XSL, XSLT, DOM, SAX, JAXP, JAXB, XML Spy, XML-Query, SOAP,
WSDL, Web services ,Xfire, EDI, XPATH, X12, Xml editor stylusstudio , ALTOVA , BPML, HIPAA, HL7.
IDE:
Eclipse3, WSAD, Web Logic work shop, Net Beans, RAD, J developer, J builder , Intelli J IDE, Edit plus, KAWA.
JAVA Build Tools: Log4J, logback,
Version Control Tools: VSS(Team Foundation Server ), VSS, Harvest ,Rational Clear Case.
ORM TOOLS----Hibernate, Oracle Top Links, I Batis
Performance tuning ----- JConsole, JProfile, Manage Engine
OOAD Design Tools: MS Visio, Rational Rose, together.
Reporting Tools: JFree Pie Chart, Crystal, iText, Jasper Reports, BIRT,Informatica , BOXI.
Testing tools: Test director, Win Runner, Test Director, Mercury Quality Center(QTP ),
Rational Clear Quest, create test cases , Unit, Regression System , Integration Testing,
ATLAS, Capture ,Remidi Bug Tracking Tool, Bug Reporting,
SDLC Methodology: Waterfall, V Model, TDD, Agile software development
Tools: Cute FTP, PUTTY, Smart FTP, Real VNC Viewer, Dam Ware Remote Control system Access, Oracle Identity Management, Agile, JProbe, RSA, Smart FTP, Real VNC Viewer, PUTTY.
Operating Systems: WindowsXP/NT/98/2k, DOS, UNIX, AIX, Sun Solaris, LINUX, Unix Shell Scripting.

MS office -Word, Excel, Power Point.,
J2EE Design Patterns --Value object (VO) =DTO having all set /get methods like bean
DAO Interface ,DAO impl is a bean or class
Developed implementation plans for shipping the services to System, Performance, UAT and Production boxes.
SDLC methodologies: V model ,Water fall model,SCRUM, XP, TDD , Agile

JAVA SDLC models

scrum-vs-xp-why-scrum

ORM TOOLS

HIBERNATE
BEA KODO

IBATIES ORM TOOL
IBATIES ORM TOOL

ant and Maven scripts

Java Project build tools Maven ,ant groovy..

Here some of links will explain very clearly

ANT and Groovy

building-web-applications-with-maven-2

ant-build-script-for-java-web-application
build.xml

maven-1.x using war

Ant+Jetty+Plugin

roseindia-----jboss---buildingwebapplicationwithant


tomcat-6.0-doc-appdev-build.xml

some of the other scripting tools for build the application
make, gnumake, nmake, jam
groovy

java load and stress testing tool

apache Jmeter

Jmeter is one of the Java tools which is used to load testing client/server applications. Earlier it was used for testing Web Applications only however now-a-days its being used for other test functions. It is typically used to measure performance and to load test functional behavior of client-server applications. It can also handle FTP and JDBC requests. You must be aware of such other tools like WinRunner. You will be glad to know that as compared to WinRunner, Jmeter is easy to use due to its simple and intuitive GUI. Moreover its absolutely free and can be modified at ease as its an open

Apache jmeter testing tool

JAVA RELATED

SINGLE SIGN ON
Java Platform Overview Key packages of the Java platform



Unit Testing framework easymock
Unit Testing for JAVA--Testng framework
EAI
EAI on ITTOOLBOX


unix
eclipse
objectweb
libresource
eclipse plugins
sysdeo pulg in for eclipse tomcat

ContentManagementTools

contenet management tools

AJAX

Introduction to AJAX
ajaxpatterns
java stuff
ajax javaee 5
arctechsoftware

SAS training meterial

SAS


taleo
web works
TheRegistersite for softwares
GENERICS JAVA 6 new features
Java SE6

Spoken English

freeenglishnow for spoken english
english pictures
chicago catalist

PHP training

PHP

Oracle DBA

oracle news

java Oracle performence

java Oracle performence
oracle news

bea weblogic portals version 10

Introduction to bea portals
Web Logic portals
bea web logic
weblogic version 10
www.javacoffeebreak.com

iText reports

iText reports
text to pdf converted software
Web-based Oracle Reports
Jasper Report from Java
cold fusion
Design patterns
OOPS
RSA feed creation from sites
enterprise applications
sun java studio
SUN Training
EJB 3
Build Flexible Logs With log4j
designpatterns

java interview question

Version control Technologies in JAVA

Go through this article ,here explain detail


versioncontrol

Spring example guide

It is good Example See this site spring examples

SaxParserProject examples

-------------------Spring frame work ----------------

spring reference
spring
struts spring

java interview Questions

• http://www.bestjavainterviewquestions.com/
  
• http://javaprepare.blogspot.com/
  
• http://www.blogtoplist.com/
  
• http://www.bestjavainterviewquestions.com/
  
• https://www.blogcatalog.com/
  

• http://javainterviewquestions.50webs.com/
  
• http://stores.lulu.com/
  
• http://www.rajwanshi.com/
  
• http://www.developersbook.com/
  
• http://faqs.javabeat.net/
  
java interview questions interview questions from javagalaxy JGuru Java faqs java boutique interview questions exforsys EJB INTERVIEW QUESTIONS geek interview questions java 2 s interview questions

ORACLE FAQS

http://blog.sqlauthority.com/

http://www.coolinterview.com/type.asp?iType=8

http://www.orafaq.com/

http://www.techonthenet.com/oracle/index.php

http://www.vishalon.net/TechyStuffs/SQLFAQs/tabid/128/Default.aspx

http://www.orafaq.com/cgi-bin/sqlformat/pp/utilities/sqlformatter.tpl

Some info on outer joins
Query A: Oracle Outer Join Syntax

view plaincopy to clipboardprint?

SELECT d.dname, d.deptno, e.ename
FROM dept d, emp e
WHERE d.deptno = e.deptno(+) and
d.deptno in (10,40)

SELECT d.dname, d.deptno, e.ename
FROM dept d, emp e
WHERE d.deptno = e.deptno(+) and
d.deptno in (10,40)
Query B: ANSI Outer Join Syntax Version 1

view plaincopy to clipboardprint?

SELECT d.dname, d.deptno, e.ename
FROM dept d LEFT OUTER JOIN emp e
ON d.deptno = e.deptno
WHERE d.deptno in (10,40)

SELECT d.dname, d.deptno, e.ename
FROM dept d LEFT OUTER JOIN emp e
ON d.deptno = e.deptno
WHERE d.deptno in (10,40)
Query C: ANSI Outer Join Syntax Version 2

view plaincopy to clipboardprint?

SELECT d.dname, d.deptno, e.ename
FROM dept d LEFT OUTER JOIN emp e
ON d.deptno = e.deptno and
d.deptno in (10,40)

SELECT d.dname, d.deptno, e.ename
FROM dept d LEFT OUTER JOIN emp e
ON d.deptno = e.deptno and
d.deptno in (10,40)
Do note the slight difference between the two ANSI versions: Query B has the filter predicate in the WHERE clause, where Query C has the filter predicate in the ON clause.

Query Results
Query A

DNAME DEPTNO ENAME
-------------- ---------- ----------
ACCOUNTING 10 CLARK
ACCOUNTING 10 KING
ACCOUNTING 10 MILLER
OPERATIONS 40

4 rows selected.
Query B

DNAME DEPTNO ENAME
-------------- ---------- ----------
ACCOUNTING 10 CLARK
ACCOUNTING 10 KING
ACCOUNTING 10 MILLER
OPERATIONS 40

4 rows selected.
Query C

DNAME DEPTNO ENAME
-------------- ---------- ----------
ACCOUNTING 10 CLARK
ACCOUNTING 10 KING
ACCOUNTING 10 MILLER
RESEARCH 20
SALES 30
OPERATIONS 40

6 rows selected.

create Log4J messages for testing system

Log4J messages for testing system

by SIRISH

create Log4J messages for testing system

http://www.openqa.org/ For QA testing

It os good quality control tectonics here please check 

http://www.openqa.org

A JAVA OPEN SOURCE  softwares

http://java-source.net/

Cruise Control configuaration

Cruise Control configuaration
Nice article on How to Configure cruise control...

cruisecontrol

testing for java

JConsole   java based load testing 

DBUnit   unit testing 

httpunit for unit testing

Implemented Caching using Apache JCS.

http://jakarta.apache.org/jcs/

Used JaSypt to store encrypted data in the database.

http://www.jasypt.org/features.html

         

openn cmd promt

java -Dcom.sun.management.jmxremote Testfile

open another  cmd and type jconsole

fire bug for fire fox browser

fire bug plug in for firefox brower add on for the html content dynamically edit and view option but not saved .it is easy to delete some of the div ,colors etc.

Servers and port numbers

Oracle 1521

bea weblogic 7001 HTTPS 7002

tomcat 8080 https 8081

Web sphere  server 

JBOSS 8080

Point Base databse  database is bea default database for Portals and content managenet

• DB2: 50000 and 50001
• SQL Server: 1433
  
• LDAP: 389 is the default, but if you choose to separate your LDAP server from your WebSphere servers with a firewall, this port will also need to be configured.

bootstrapPort	900	admin.config	admin.config	server-cfg.xml
lsdPort	9000
LSDSSLPort	9001
HTTP transport port	9080	Database	Database
HTTPS transport port	9443

SSO(single sign On)

oracle oblix  in wiki

bea Netegrity 

Netegrity Siteminder(CA ) provides web SSO and authorization services 

Portal servers in IT Market

Enterprise Platform Vendors:

1. SAP - SAP Enterprise Portal
2. Computer Associates - CleverPath Portal
3. Oracle - PeopleSoft Enterprise Portal

Application Server Portals - These products are extensions of Java application servers:

1. IBM - Websphere Portal Server
2. Sun - Sun Java System Portal Server
3. BEA - WebLogic Portal
4. Oracle - Oracle Portal

Pure-Play Providers:

1. Vignette - Vignette Application Portal (VAP)
2. Plumtree - Plumtree Corporate Portal

Departmental Portals:

1. Microsoft - SharePoint Portal Server

Specialty Portal Products:

1. ATG - Dynamo e-Business Platform
2. Broadvision - Broadvision Portal

Major Open Source Portals:

1. Apache Project - Jetspeed 2 Enterprise Portal
2. Zope - Plone

JSON

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

JSON is built on two structures:

• A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangable with programming languages also be based on these structures.

Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.

The single most important problem that SAML is trying to solve is the Web Browser Single Sign-On (SSO) problem. Single sign-on solutions are abundant at the intranet level (usingcookies, for example) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies. SAML has become the definitive standard underlying many web Single Sign-On solutions in the enterprise identity management problem space.

http://www.youtube.com/results?search_query=extjs&search_type=&aq=f

JSON

http://www.youtube.com/watch?v=PoW1EZR7S80

http://sitepen.com/labs/guides/?guide=DojoQuickStart   

http://www.youtube.com/watch?v=8mwKq7_JlS8 

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.

HIPAA ,US Standards in Health Insurence

FAQs About Electronic Transaction Standards Adopted Under HIPAA

---

Questions

• Why have national standards for electronic health care transactions been adopted? Why are they required?
• What health care transactions are required to use the standards under this regulation?
• Who is required to use the standards?
• If a health plan does not perform a transaction electronically, must it implement the standard?

• When will the standards become effective?
• Where did these standards come from? Did the Federal Government create them?
• What standards were chosen?
• Do these standards apply to transactions sent over the Internet?
• Do I have to use standard transactions when conducting business inside my corporate boundaries?

• What is the effect of these standards on State law?
• Are any exceptions allowed?
• What does the law require of State Medicaid programs?

• How will the standards be enforced?
• How were the standards chosen?
• Where can I obtain implementation guides for the standards?
• How can the standards be changed? (updated 9/8/2000)

• Does the law require physicians to buy computers?
• How will the standards affect data stored in my system?

• Can health plans require changes or additions to the standard claim?
• Should health plans publish companion documents that augment the information in the standard implementation guides for electronic transactions?
• Could companion documents from health plans define cases where the health plan wants particular pieces of data used or not used?
• May health plans stipulate the codes or data values they are willing to accept and process in order to simplify implementation?
• May health plans stipulate the number of loop iterations or the file sizes they are willing to accept?

---

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.

---