Medical billing is the process of submitting and following up on claims to insurance companies in order to receive payment for services rendered by a healthcare provider. The same process is used for most insurance companies, whether they are private companies or government-owned. Medical billers are strongly encouraged, but not required by law to become certified by taking an exam such as the Certified Medical Reimbursement Specialist Exam (CMRS Exam).
Contents
1 Billing Process
2 Electronic Billing Process
3 Payment
4 History
5 HIPAA
6 Patient Demographics
7 References

Billing Process

The medical billing process is an interaction between a healthcare provider and the insurance company (payer). The interaction begins with the office visit: A doctor or their staff will typically create or update the patient's medical record. This record contains a summary of treatment and demographic information(patients name,address,social security number,home telephone number,work telephone number,policy identity number for the respective insurance holded by the patient...if the patient is minor the guarantor information should be updated) related to the patient. Upon the first visit, the provider will usually give the patient one or more diagnoses in order to better coordinate and streamline his/her care. In the absence of a definitive diagnosis, the reason for the visit will be cited for the purpose of claims filing. The patient record contains highly personal information: the nature of illness, examination details, medication lists, diagnoses, and suggested treatment.
The extent of the physical examination, the complexity of the medical decision making and the background information (history) obtained from the patient are evaluated to determine the correct level of service that will be used to bill the insurance. The level of service, once determined by qualified staff is translated into a five digit procedure code from the Current Procedural Terminology. The verbal diagnosis is translated into a numerical code as well, drawn from the ICD-9-CM. These two codes, a CPT and an ICD-9-CM, are equally important for claims processing.
Once the procedure and diagnosis codes are determined, the medical biller will transmit the claim to the insurance company (payer). This is usually done electronically by formatting the claim as an ANSI 837 file and using Electronic Data Interchange to submit the claim file to the payer directly or via a clearinghouse. Historically, claims were submitted using a paper form; in the case of professional (non-hospital) services and for most payers the CMS-1500 form or HICF (Health Insurance Claim Form)was and is still commonly used. The CMS-1500 form is so named for its originator, the Centers for Medicare and Medicaid Services. To this day about 30% of medical claims get sent to payers using paper forms which are either manually entered or entered using automated recognition or OCR software.
The insurance company (payer) processes the claims usually by medical claims examiners or medical claims adjusters. For higher dollar amount claims, the insurance company has medical directors review the claims and evaluate their validity for payment using rubrics(procedure) for patient eligibility, provider credentials, and medical necessity. Approved claims are reimbursed for a certain percentage of the billed services. These rates are pre-negotiated between the health care provider and the insurance company. Failed claims are rejected and notice is sent to provider. Most commonly, rejected claims are returned to providers in the form of Explanation of Benefits (EOB's) or Remittance Advice.
Upon receiving the rejection message the provider must decipher the message, reconcile it with the original claim, make required corrections and resubmit the claim. This exchange of claims and rejections may be repeated multiple times until a claim is paid in full, or the provider relents and accepts an incomplete reimbursement. Without Medical billing providers can no longer be getting paid for the services given by them and healthcare process cycle will be affected.
The frequency of rejections, denials, and over payments is high (often reaching 50%)(HBMA 7/07 [1]), mainly because of high complexity of claims and/or errors due to similarities in diagnosis' and their corresponding codes. This number may also be high due to insurance companies denying certain services that they do not cover (or think they can get away without covering) in which case small adjustments are made and the claim is re-sent. Finished no changes
Electronic Billing Process

A practice that has interactions with the patient must now under HIPAA send most billing claims for services via electronic means. Prior to actually performing service and billing a patient, the care provider may use software to check the eligibility of the patient for the intended services with the patient's insurance company. This process uses the same standards and technologies as an electronic claims transmission with small changes to the transmission format, this format is known specifically as X12-270 Health Care Eligibility & Benefit Inquiry transaction [2]. A response to an eligibility request is returned by the payer through a direct electronic connection or more commonly their website. It is called an X12-271 "Health Care Eligibility & Benefit Response" transaction. Most practice management/EMR software will automate this transmission, making them hidden from the user.
This first transaction for a claim for services is known technically as X12-837 or ANSI-837, and it contains a large amount of data regarding the provider interaction as well as reference information about the practice and the patient. Following that submission, the payer will respond with an X12-997, simply acknowledging that the claim's submission was received and that it was accepted for further processing. When the claim(s) are actually adjudicated by the payer, the payer will ultimately respond with a X12-835 transaction, which shows the line-items of the claim that will be paid or denied; if paid, the amount; and if denied, the reason.
Due to limited technology, many payers (especially states' Medicaid) still adjudicate claims manually; this results in significant delays — up to 48 hours or even weeks to issue 835 responses to properly submitted 837 transactions. In many cases this manual processing subverts the entire point of Congress in mandating a standardized electronic billing process. These delays can also present catastrophic problems to the availability of healthcare for those patients with difficult payers — such as happened in California with the state Medicaid program referred to as "Medi-cal"[3].
Payment

In order to be clear on the payment of a medical billing claim, the health care provider or medical biller must have complete knowledge of different insurance plans that insurance companies are offering, and the laws and regulations that preside over them. Large insurance companies can have up to 15 different plans contracted with one provider. When providers agree to accept an insurance company’s plan, the contractual agreement includes many details including fee schedules which dictate what the insurance company will pay the provider for covered procedures and other rules such as timely filing guidelines.
Providers typically charge more for services than what has been negotiated by the doctor and the insurance company, so the expected payment from the insurance company for services is reduced. The amount that is paid by the insurance is known as an allowable amount. For example, although a psychiatrist may charge $80.00 for a medication management session, the insurance may only allow $50.00, so a $30 reduction would be assessed. This is called a "provider write off" or "contractual adjustment." After payment has been made a provider will typically receive an Explanation of Benefits (EOB) or Electronic Remittance Advice (ERA) along with the payment from the insurance company that outlines these transactions.
The insurance payment is further reduced if the patient has a copay, deductible, or a coinsurance. If the patient in the previous example had a $5.00 copay, the doctor would be paid $45 by the insurance. The doctor is then responsible for collecting the out-of-pocket expense from the patient. If the patient had a $500.00 deductible, the contracted amount of $50 would not be paid by the insurance company. Instead, this amount would be the patient's responsibility to pay, and subsequent charges would also be the patient's responsibility, until his expenses totaled $500. At that point, the deductible is met, and the insurance would issue payment for future services.
A coinsurance is a percentage of the allowed amount that the patient must pay. It is most often applied to surgical and/or diagnostic procedures. Using the above example, a coinsurance of 20% would have the patient owing $10 and the insurance company owing $40.
In Medicare the physician can either be 'Participating' in which he will receive 80% of the allowable Medicare fee and 20% will be sent to the patient or can be 'Nonparticipating' in which the physician will receive 80% of the fee, and may bill patients for 15% or more on the scheduled amount.
For example the regular fee for a particular service is $100, while Medicare's fee structure is $70. Therefore the physician will get $56, and the patient will pay $14. Similarly Medicaid has its own set of policies which are slightly more complex than Medicare.
Steps have been taken in recent years to make the billing process clearer for patients. The Healthcare Financial Management Association (HFMA) unveiled a "Patient-Friendly Billing" project to help healthcare providers create more informative and simpler bills for patients. Additionally, as the Consumer-Driven Health movement gains momentum, payers and providers are exploring new ways to integrate patients into billing process in a clearer, more straightforward manner.[4]
History

For several decades, medical billing was done almost entirely on paper. However, with the advent of medical practice management software also known as health information systems it has become possible to efficiently manage large amounts of claims. Many software companies have arisen to provide medical billing software to this particularly lucrative segment of the market. Several companies also offer full portal solutions through their own web-interfaces, which negates the cost of individually licensed software packages.
Due to the rapidly changing requirements by U.S. health insurance companies, several aspects of medical billing and medical office management have created the necessity for specialized training. Medical office personnel may obtain certification through various institutions who may provide a variety of specialized education and in some cases award a certification credential to reflect professional status. The Certified Medical Reimbursement Specialist (CMRS) accreditation by the American Medical Billing Association is one of the most recognized of specialized certification for medical billing professionals.
HIPAA

The billing field has been challenged in recent years due to the introduction of the Health Insurance Portability and Accountability Act (HIPAA).
HIPAA is a set of rules and regulations which hospitals, doctors, healthcare providers and health plans must follow in order to provide their services aptly and ensure that there is no breach of confidence while maintaining patient records.
Since 2005, medical providers have been urged to electronically send their claims in compliance with HIPAA to receive their payment.
Title I of this Act protects health insurance of workers and their families when they change or lose a job. Title II calls for the electronic transmission of major financial and administrative dealings, including billing, electronic claims processing, as well as reimbursement advice.
Medical billing service providers and insurance companies were not the only ones affected by HIPAA regulations - many patients found that their insurance companies and health care providers required additional waivers and paperwork related to HIPAA.
As a result of these changes, software companies and medical offices spent thousands of dollars on new technology and were forced to redesign business processes and software in order to become compliant with this new act. If an insured claim is billed by another insured with a different name than that might be a big issue by the insurance companies.
Patient Demographics

The medical billing specialists enter patient, and if applicable guarantor demographic details such as name, date of birth, address, insurance details as provided by the patients at the time of the visit. For established patients, these details are validated.

References

1. Upgraded supports for Http, J2SE, and J2EE: Servlet 2.4 depends on Http1.1 and J2SE 1.3.
2. Additional ServletRequest methods : In Servlet 2.4 four new methods are added in the ServletRequest 
   
   • getRemotePort(): It returns the IP source port of the client.
   • getLocalName(): It returns the host name on which the request was recieved.
   • getLocalAddr(): It returns the IP addresson which the request was recieved. 
   • getLocalPort(): It returns the IP port number.
3. New Support for internationalization and charset choice: For  the support of internationization Servlet 2.4 has added to new methods in the ServletReponse interface. 
   
   • setCharacterEncoding(String encoding): The purpose of this method is to set the response's character encoding.  This  method helps us to pass a charset parameter tosetContentType(String) or passing a Locale to setLocale(Locale). We can now avoid setting the charset in the setContentType("text/html;charset=UTF-8") assetCharacterEncoding() methods pairs with the preexistinggetCharacterEncoding() method to manipulate and view the response's character encoding.
      
   • getContentType(): It is responsible for returning the response's content type. The content type can be dynamically set with a combination of setContentType(),setLocale(), and setCharacterEncoding() calls, and the method getContentType()provides a way to view the generated type string. 
4. New features has been added in RequestDispatcher: In Servlet 2.4 five new request attributes has been added to provide the extra information during a RequestDispatcherforward() call. This features has been added is Servlet 2.4 to know the true original request URI. The following request attributes are:
   
   • javax.servlet.forward.request_uri
   • javax.servlet.forward.context_path
   • javax.servlet.forward.servlet_path
   • javax.servlet.forward.path_info
   • javax.servlet.forward.query_string
5. SingleThreadModel interface has been deprecated: In Servlet 2.4 the SingleThreadModel interface has been deprecated. 
6. HttpSession details and interaction with logins has been clarified: The new method HttpSession.logout() has been added in the Servlet 2.4. Now session allows zero or negative values in the < session-timeout> element to indicate sessions should never time out.
   If the object in the session can't be serialized in a distributed environment then it must throw an IllegalArgumentException. 
7. Welcome file behavior and Classloading has been clarified: In servlet 2.4 welcome file can be servlets. 
8. The web.xml file now uses XML Schema: Version 2.4 servers must still accept the 2.2 and 2.3 deployment descriptor formats, but all new elements are solely specified in Schema.

1. Dependency on J2SE 5.0: The minimum platform requirement for Servlet2.5 is JDK 1.5. Servet2.5 can't be used in versions below that JDK1.5. All the available features of Jdk1.5 like generics, autoboxing, an improved for loop etc, etc are guaranteed available to Servlet2.5programmers. 
2. Support For annotations: Annotations provide a mechanism for decorating java codeconstructs (classes, methods, fields, etc.) with metadata information. Annotations are mark code in such a way that code processors may alter their behavior based on the metadata information. 
3. Several web.xml convenience: Servlet 2.5 introduces several small changes to the web.xml file to make it more convenient to use.  For example while writing a , we can now use a asterisk in a which will represent all servlets as well as Jsp.
   
   Previously we used to do
   
   < filter-mapping>
   < filter-name>FilterName
   < servlet-name>FilterName
   < /filter-mapping> 
   Now,
   
   < filter-mapping>
   < filter-name>FilterName
   < servlet-name>*
   < /filter-mapping>
    
   Previously in < servlet-mapping> or < filter-mapping> there used to be only one < url-pattern>, but now we can have multiple < url-pattern>, like
   
   < servlet-mapping>
       < servlet-name>abc< /servlet-name>
       < url-pattern>/abc/*< /url-pattern>
       < url-pattern>/abc/*< /url-pattern>
   < /servlet-mapping> 
   Apart from these changes, many more facilities added in web.xml. 
4. A Handful of removed restrictions: Servlet 2.5 removed a few restrictions around error handling and session tracking. Now it has removed the restriction that the could not call the setStatus() method to alter the error code that triggered them. In session tracking, Servlet 2.5 eased a rule that a servlet called by RequestDispatcher include() couldn't set response headers. 
5. Some edge case clarifications: : The servlet2.4 specification says that before callingrequest.getReader() we  must call request.setCharacterEncoding().  However there is no such clarification given why it is so. It has been described properly in Servlet 2.5.

1. Platform Independence
   Java Servlets are 100% pure Java, so it is platform independent. It can run on any Servlet enabled web server. For example if you develop an web application in windows machine running Java web server. You can easily run the same on apache web server (if Apache Serve is installed) without modification or compilation of code. Platform independency of servlets provides a great advantage over alternatives of servlets.
2. Performance
   Due to interpreted nature of java, programs written in java are slow. But the java servlets runs very fast. These are due to the way servlets run on web server. For any program initialization takes significant amount of time. But in case of servlets initialization takes place very first time it receives a request and remains in memory till times out or server shut downs. After servlet is loaded, to handle a new request it simply creates a new thread and runs service method of servlet. In comparison to traditional CGI scripts which creates a new process to serve the request. This intuitive method of servlets could be use to develop high speed data driven websites.
3. Extensibility
   Java Servlets are developed in java which is robust, well-designed and object oriented language which can be extended or polymorphed into new objects. So the java servlets takes all these advantages and can be extended from existing class the provide the ideal solutions.
4. Safety
   Java provides a very good safety features like memory management, exception handling etc. Servlets inherits all these features and emerged as a very powerful web server extension.
5. Secure
   Servlets are server side components, so it inherits the security provided by the web server. Servlets are also benefited with Java Security Manager.

Java Servlet API contains two core packages:

• javax.servlet
• javax.servlet.http

1. service() metho called by servlet to handle the client request in a new thead. service() methos accepts ServletRequest and a ServletResponse ohjects as parameters. ServletRequestobject represents the client request. It contains the data sent in name/value pairs.ServletResponse object is used to send the response to the client.
2. init() is called once when servlet is loaded. It is a good place to initialize global variables. This methos accepts ServletConfig as parameter which provides initialization arguments for the servlet.
3. getServletConfig() returns the ServletConfig object passed to init().
4. destory() is called when wervlet is unloaded from memory. This is a good place to clean up any resources(such as open files or database connections).
5. getServletInfo() returns a string with version, copyright informations etc.

The servlet run inside a Web Server program. After it has been compiled, it must be installed onto Web Server in order to test it. Thus we have to follow the following steps:

1. Install the servlet in a hosting server
2. Request the servlet through web browser.

1. Download the distribution of Java Web Server from http://www.javasoft.com/products . Distribution is in the form of self-extracting file.
2. The Java Web Server can be installed in any directory, so you can choose your favorite directory for installation. Move the downloaded file into your favorite directory.
3. To begin the installation just double-click on the self-extracting file and the file extract itself and then installation begins.
4. Follow the instruction and complete the installation.

• what a custom tag library is,
• why you want to use a custom tag library,
• the composition of a tag library, and
• how to build and use a complete library.

What a Custom Tag Library Is

• be customized via attributes passed from the calling page, either staticly or determined at runtime;
• have access to all the objects available to JSP pages including request, response, in and out;
• modify the response generated by the calling page;
• communicate with each other; you can create and initialize a JavaBeans component, create a variable that refers to that bean in one tag, and then use the bean in another tag;
• be nested within one another, allowing for complex interactions within a JSP page; and
• encapsulate both simple and complex behaviors in an easy to use syntax and greatly simplify the readability of JSP pages.

The Composition of a Tag Library

< taglib>	The tag library itself.
< tlibversion>	The tag library's version.
< jspversion>	The JSP specification version the tag library depends on.
< shortname>	A simple default name with a mnemonic value. For example, may be used as the preferred prefix value in taglib directives and/or to create prefixes for IDs.
< uri>	A optional URI that uniquely identifies the tag library.
< info>	Descriptive information about the tag library.

< ?xml version="1.0" encoding="ISO-8859-1" ?>
< !DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" 
"http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
< taglib>
 < tlibversion>1.0
 < jspversion>1.1
 < shortname>oreillySamples
 < info>OReilly Sample Tag library
  < !-A Simple tag -->
  < tag>
    < name>hello
    < tagclass>oreilly.examples.Hello < /tagclass>
  < !--Body content can have a value of 
    empty: no body 
      JSP: body that is evaluated by container, then possibly processed by the tag 
      tagdependent: body is only processed by tag; JSP in body is not evaluated.
   -- >
    < bodycontent>empty
    < info>
 This is a simple hello tag.
    < /info>
  < !-- Optional attributes  -->
  < !- personalized name -->
  < attribute>
      < name>name< /name>
      < required>false< /required>
      < rtexpvalue>false< /rtexpvalue>
  < /attribute>
< /tag>
< /taglib>

If your Tag Handler:	You need to implement the following methods:
has no attributes and no body	doStartTag, doEndTag, release
has attributes	doStartTag, doEndTag, set/getAttribute1...N
has a body with no interaction	doStartTag, doEndTag, release
has a body with interaction	doStartTag, doEndTag, release, doInitBody, doAfterBody

package oreilly.examples
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
/**
 * This is a simple tag example to show how content is added to the
 * output stream when a tag is encountered in a JSP page. 
 */
public class Hello extends TagSupport {
 private String name=null;
    /**
      * Getter/Setter for the attribute name as defined in the tld file 
      * for this tag
      */
public void setName(String value){
    name = value;
}

 public String getName(){
          return(name);
       }
/**
* doStartTag is called by the JSP container when the tag is encountered
*/
    public int doStartTag() {
   try {
        JspWriter out = pageContext.getOut();
        out.println("< table border="\1\">");
      if (name != null)
       out.println("< tr>< td> Hello " + name + " < /td>< /tr>");
        else
       out.println("< tr>< td> Hello World < /td>< /tr>");
   } catch (Exception ex) {
     throw new Error("All is not well in the world.");
   }
   // Must return SKIP_BODY because we are not supporting a body for this 
   // tag.
   return SKIP_BODY;
    }
/**
 * doEndTag is called by the JSP container when the tag is closed
 */
 public int doEndTag(){
    try {
         JspWriter out = pageContext.getOut();
        out.println("< /table>");
    } catch (Exception ex){
      throw new Error("All is not well in the world.");
    }
 }
}

The JSP

Once your TLD and tag handlers are created, you can begin accessing the tags in your JSP. You declare that a JSP page will use tags defined in a tag library by including a taglib directive in the page before any custom tag is used. The prefix attribute is a shortcut to referencing the library throughout the page.
Sample Hello.jsp:
< %@ taglib uri="/oreillySample.tld" prefix="sample" %>
< html>
        < head>
                < title>Your Standard Hello World Demo
        < /head>
        < body bgcolor="#ffffff">
                < hr />
                < sample:hello name="Sue"/>
                < hr />
        < /body>
< /html>
The HTML source output from this JSP would look like:
< html>
        < head>
                < title>Your Standard Hello World Demo< /title>
        < /head>
        < body bgcolor="#ffffff">
                < hr />
        < table border="1">
          < tr>< td> Hello Sue < /td>< /tr>
                < /table>
                < hr />
        < /body>
< /html>
You can see how the tag was evaluated and the contents of the tag inserted into the output stream.
If you wanted to add functionality to our tag to make it more flexible, say to evaluate a body a certain number of times and make the name attribute evaluated at runtime, you can do so fairly easily with a few changes. First you would make the following changes to the TLD file. The tag definition would look like
  < tag>
    < name>hello
    < tagclass>oreilly.examples.Hello < /tagclass>
 < !-- Allow for a body to be included for this tag -->
    < bodycontent>JSP
    < info>
 This is a simple hello tag.
    < /info>
    
    < !-- Optional attributes  -->
    < !-- personalized name -->
    < attribute>
      < name>name< /name>
      < required>false< /required> 
    < rtexpvalue>true< /rtexpvalue>
    < /attribute>
    < !-allow for the jsp coder to specify how many times to iterate -->
    < attribute>
      < name>iterations< /name>
      < required>false< /required> 
    < rtexpvalue>false< /rtexpvalue>
    < /attribute>

< /tag>
Then you must alter the handler class by extending TagBodySupport and implementing the body methods if you wanted different behavior from that provided in the base class implementation. The handler class would now look like
public class Hello extends BodyTagSupport {
 private String name=null;
    private int iterations=1;

 /**
     * Getter/Setter for the attribute name as defined in the tld file 
     * for this tag
     */
 public void setName(String value){
  name = value;
 }

 public String getName(){
  return(name);
 }
 /**
     * Getter/Setter for the attribute iterations as defined in the tld file 
     * for this tag
     */

 public void setIterations(String value){
     try {
       iterations = Integer.parseInt(value);
     } catch(NumberFormatException nfe) {
       iterations = 1;
     } 
   }

 public String getIterations(){
  return(Integer.toString(iterations));
 }

    public int doStartTag() throws JspTagException{
   try {
        JspWriter out = pageContext.getOut();
        out.println("< table border=\"1\">");
      if (name != null)
       out.println("< tr>< td> Hello " + name + " < /td>< /tr>");
        else 
       out.println("< tr>< td> Hello World < td>< /tr>");
   } catch (Exception ex) {
     throw new JspTagException("All is not well in the world." + ex );
   }
   // Evaluate the body if there is one
   return EVAL_BODY_TAG;
    }

 public int doEndTag()throws JspTagException {
    try {
         JspWriter out = pageContext.getOut();
        out.println("< /table>");
    } catch (Exception ex){
      throw new JspTagException("All is not well in the world." + ex);
    }
 }

 public int doAfterBody() throws JspTagException {
    if (iterations-- >= 1) {
      BodyContent body = getBodyContent();
      try {
  // Make sure we put anything in the output stream in the 
  // body to the output stream of the JSP
        JspWriter out = body.getEnclosingWriter();
        out.println(body.getString());
        body.clearBody(); // Clear for next evaluation
      } catch(IOException ioe) {
        throw new JspTagException("Error in Hello tag doAfterBody " + ioe);
      }
      return(EVAL_BODY_TAG);
    } else {
      return(SKIP_BODY); 
 }
}
Now let's make the simple changes in the JSP file. Our sample Hello.jsp looks like
< %@ taglib uri="/oreillySample.tld" prefix="sample" %>
< %!
    // allow a username to be passed in the request
    String userName = request.getParameter("NAME");
% >

< html>
        < head>
                < title>Your Standard Hello World Demo < /title>
        < /head>
        < body bgcolor="#ffffff">
                < hr />
                < sample:hello name="" iterations="2" >
   < tr>< td>Have a nice day< /b>< /td>
   < /sample:hello>
                < hr />
        < /body>
< /html>

If our JSP page was called like hello.jsp?NAME=Sue our output would look like
< html>
        < head>
                < title>Your Standard Hello World Demo
        < / head>
        < body bgcolor="#ffffff">
                < hr />
        < table border="1">
          < tr>< td> Hello Sue < /td>< /tr>
     < tr>< td>< b>Have a nice day< /b>< /td>< /tr>
     < tr>< td>< b>Have a nice day< /b>< /td>< /tr>
                < /table>
                < hr />
        < /body>
< /html>
This simple example is but a small glimpse at the power of custom tag libraries. We examined how to create and use a simple tag library and then easily extend its functionality. The next article will examine some of the advanced features of tags, including defining scripting variables and cooperating tags. It will also go through working examples of each.