Vasectomies are very common in most urology practices. But choosing the proper codes to report can sometimes prove very challenging, right from the pre-vasectomy “consultation” visit that most urologists perform. You could be costing your practice hundreds over the course of one year if you’re not billing out each piece of the vasectomy process. Here are four steps to ensure that you capture all the reimbursement your urologist deserves.

1. Don’t be in a hurry to assign consult codes for the first visit

Prior to performing a vasectomy process a urologist meets with the patient to discuss the procedure and makes sure that the patient understands the outcome of the procedure and then undergo this elective sterilization. You should report this office visit using the appropriate E/M code, says Kelly Young, a coder with Scottsdale Center for Urology in Scottsdale, Ariz.

The real challenge comes when you try to figure out whether you should report an office visit E/M code or a consultation code.

Depending on your urologist’s documentation, you can choose from the consultation codes (99241-99245, Office consultation for a new or established patient …), a new patient (99201-99205, Office or other outpatient visit for the evaluation and management of a new patient …), or established patient (99211-99215, Office or other outpatient visit for the evaluation and management of an established patient …) codes.

Don’t lose out on your Dollars: You would be sacrificing on your Dollars if you skip reporting the pre-vasectomy office visit. Suppose, your urologist performs a level-three new patient visit (99203), you’ll earn $91.97 (the unadjusted fee for 99203, 2.55 RVUs, times the 2009 conversion rate of $36.0666) in addition to the procedure code, and if your urologist performs a level-three consultation, you’ll earn $125.15 (the unadjusted fee for 99203, 3.47 RVUs, times the 2009 conversion rate of $36.0666) in addition to the procedure code.

Remember: If the patient is new to your office, report a new patient visit using codes 99201-99205. However, if the urologist (or another urologist in the same practice) has seen the patient within the past three years, report an established patient office visit (99211-99215), and not a new patient visit.

Beware: Don’t let the term “consultation” in the physician’s documentation trick you. Often practices, physicians, and even patients refer to the pre-vasectomy visit as a consultation. However, to report a consultation code (99241-99245), the visit must meet the requirements of a consultation. There must be a documented request from the requesting physician; a record of the urologist stating his findings, opinions, and advice in the patient’s chart; and a report that’s sent back to the requesting doctor.

Michael A. Ferragamo MD, FACS, clinical assistant professor of urology, State University of New York, Stony Brook says, “Since the recent rule changes for consultations come from Medicare 2006 policy changes (Transmittal 788) and since most men seeking vasectomies for sterilization do not have Medicare as their primary insurance carrier, the patients sent to urologists by physicians most often represent consultation requests , hence, they should be billed and coded accordingly if all criteria for a consultation are met.”

Diagnosis aid: The most appropriate ICD-9 code for the pre-vasectomy examination, whether it’s a consultation or a new/established patient visit is V25.09 (Encounter for contraceptive management; general counseling and advice; other).

Important point: Many payers have a perception that code V25.09 is a “family planning advice,” and pertain only to the female partner, and hence, they will deny payment for any pre-vasectomy examination of the male when you use this diagnosis. So use V25.2 (Encounter for contraceptive management; sterilization, admission for interruption of …vas deferens) in its place, with this you can expect payment for a pre-vasectomy service in most cases.

Check, which diagnostic code is preferred by your payer. The Scottsdale Center for Urology uses V25.2 as the diagnosis code. However, “we bill … with V25.09,” says Kim Kerckhoff, CCA, coder for Alpine Urology in Anchorage, Alaska.

2. Use modifier 57 for Same-Day E/M and Procedure

If your urologist performs the vasectomy procedure on the same day as the pre-vasectomy office visit make sure that you append modifier 57 (Decision for surgery) to the E/M code you report. Also ensure that the urologist’s documentation supports a separate E/M code, the E/M service must go above and beyond the E/M that’s inherent to the procedure.

Avoid bundled payment: Your urologist can conduct the service on separate days if you want to make sure that your payer will not bundle the pre-vasectomy visit with the vasectomy procedure. Many urologists do this anyway to give the patient time to review his options and make the final decision about surgery. Above that, your office will have time to review the patient’s benefits.

Alice Kater, CPC, PCS, coder for Urology Associates of South Bend, Ind says, “We never perform the procedure the same day as the vas consultation. The patient and wife/partner will come in for the consult, view a movie, and speak extensively with the physician following the examination and review of systems. When they leave the physician, they schedule their procedure for the next available, and convenient, vas opening.”

3. Select a Code Based on the Type of Procedure

You’ll have to go through the documentation to see which technique your urologist used, so that you can report the actual vasectomy procedure. Then choose one of these three codes:

55250 — Vasectomy, unilateral or bilateral (separate procedure), including postoperative semen examination(s). “This CPT Codes is the most common code used for vasectomy for voluntary sterilization,” Ferragamo explains. 55450 — Ligation (percutaneous) of vas deferens, unilateral or bilateral (separate procedure). “Coders rarely use this code for a vasectomy for voluntary sterilization,” Ferragamo says. 55559 — Unlisted laparoscopy procedure, spermatic cord for a laparoscopic vasectomy. Add V25.2 to the vasectomy procedure, says Kerckhoff. Clue: You should report 55250, 55450, or 55559 just once per patient regardless of whether the urologist performs the procedure on one or both sides. The urologist usually, but not always, performs the procedure, cutting the vas deferens and suturing the ends, on both the left and right sides. So don’t change your urology coding even if your urologist cuts and sutures only one side (for a patient having only one testicle). Note: These codes also include the local or regional anesthesia that the urologist administers, so do not code any local anesthesia administered for those services separately. Surgical trays: Use the HCPCS code A4550 (Surgical trays) or CPT code 99070 (Supplies and materials [except spectacles], provided by the physician over and above those usually included with the office visit or other services rendered [list drugs, trays, supplies, or materials provided]) for private or commercial payers, few of them reimburse for a surgical tray/supplies. “Medicare will not reimburse for anesthesia administered by the surgeon or urologist, or for tray charges,” Ferragamo warns. “However, there are a few commercial carriers that will still reimburse for local anesthesia administered by the urologist and for a tray charge. Check with the specific carrier. One may bill private or commercial carriers HCPCS code S0020 (Injection, bupivicaine HCL, 30 ml) for reimbursement of the anesthetic agent used,” he adds. There is no CPT code for laparoscopic vasectomy so when your urologist performs this procedure, usually at the same time a general surgeon is performing a laparoscopic hernia repair, report the unlisted code 55559. Hint: Make sure that you submit a detailed report to your payer and compare, or benchmark, the laparoscopic vasectomy to 55550 (Laparoscopy, surgical, with ligation of spermatic veins for varicocele), with respect to the surgical work, technology, equipment used, and time involved. 4. Include Semen Analysis in the Procedure Code After the vasectomy, the urologist must examine the semen to determine the eventual absence of sperm. These examinations are included in the procedure code, so your urologist should document the service, but you should not report them separately. If your office laboratory is not credentialed (CLIA certification) to perform these post-vasectomy semen analyses, outside laboratory evaluations will be necessary and that would result in an additional cost to the patient. However, under these circumstances your urologist should never lower his fee or modify his urology coding. Practices often make special arrangements with most laboratories for a reduced fee for a limited semen examination looking only for the presence or absence of sperm. Leesa A. Israel, CPC, CUC, CMBS, specializes in medical coding and reimbursement for urology and general surgery, as well as billing and collections policies and strategies for physician practices. More of her how-to medical coding and billing articles are available on Supercoder.com.
Article Source

How do we capture the metrics of code coverage?

The process involves Instrumentation of the program and execution of the tests. This way we can identify the code which had been executed & which had been left out. We can see that unit Testing & code coverage are complementary to each other. Unit testing confirms the compliance of program performance with respect to the requirements, whereas code coverage reveals the areas left out of the testing.

The process of development of software is aimed to have coverage measurement by way of defining the

number of branches or statements covered under the test. Even after having complete branch coverage or the statement coverage, there is no surety of absence of some key bugs in the code. Hence 100% branch coverage or the statement coverage remain quite illusive & does not provide any surety of perfection to both developers and the managers

Now the key point of discussion remains that having complete coverage remains inadequate. Reason being branch coverage as well as statement coverage do not provide any confirmation of execution of the logic of the code. Both branch coverage and statement coverage are helpful in identifying major problems in portion of the code left out of execution.

However Path coverage technique is comparatively much more rugged & helps us in revealing the defects during the early stages. Before we go deeper into path coverage, let us analyze some of the drawbacks of branch coverage and statement coverage techniques.

Statement Coverage:

Major benefit of statement coverage is that it is greatly able to isolate the portion of code, which could not be executed. Statement coverage criteria call for having adequate number of test cases for the program to ensure execution of every statement at least once. In spite of achieving 100% statement coverage, there is every likelihood of having many undetected bugs.

Thus s coverage report indicating 100% statement coverage will mislead the manager to feel happy with a false temptation of terminating further testing which can lead to release a defective code into mass production. Thus we can not view 100% statement coverage sufficient to build a reasonable amount of confidence on the perfect behavior of the application.

Since 100% statement coverage tends to become expensive, the developers chose a better testing technique called branch coverage.

http://www.softwaretestinggenius.com
A Storehouse of Complete Knowledge on Software Testing & QA under one Roof
Article Source

www.ivizsecurity.com

Somnath Guha Neogi (OSCP,CNSM)

Introduction:

ASP.NET provides several exciting security controls, but these need to be understood properly and used wisely. Failing to use the ASP.NET functions properly results in an insecure web application. We see therefore that ASP.NET does not exempt the programmer from following coding standards and procedures in order to write safe and secure application code.

In this paper we will discuss about the code level mitigation for three most frequently found vulnerabilities:

Cross Site Scripting

SQL Injection

Information Leakage

Cross Site Scripting:

An application is vulnerable to Cross Site Scripting if malicious user input is embedded in the HTML response without passing through any particular validation process. Let’s take a look on a vulnerable chunk of code

<%@ Page ValidateRequest=”false” %>

<html>

<script runat=”server”>

void buttonsubmit_Click(Object sender, EventArgs e)

{

Response.Write(comment.Text);

}

</script>

<body>

<form runat=”server”>

<asp:TextBox runat=”server” />

<asp:Button runat=”server”

Text=”SubmitComment” />

</form>

</body>

</html>

Now an attacker can send malicious request with embedded JavaScript through the comment textbox which will be executed at the client’s browser. To see that this is possible, the above vulnerable script can be fed with the following input:

<script>alert([removed])</script>

Now this type of script injection attack can be mitigated by adopting a two tire security approach. User input validation will form the first tire of security while HTML-encoding on outgoing user data will form a second layer of security. So we can start assuming that all user input is malicious and to safely allow restricted HTML input developers/testers should adopt three security approaches as follows:

a)      Add the ValidateRequest=”false” attribute to the @ Page directive to disable the ASP.NET request validation.

b)      Encode the string input with HtmlEncode function.

c)       White listing approach can be adopted by using a String Builder and calling its Replace method to selectively remove the encoding on the HTML elements that you want to permit.

The following .aspx code depicts this as an example.

<%@ Page ValidateRequest=”false”%>

<script runat=”server”>

void submitbutton_Click(object sender, EventArgs e)

{

StringBuilder stringbuilder1 = new StringBuilder(

HttpUtility.HtmlEncode(Txt1.Text));

// Selectively allow <b> and <i>

stringbuilder1.Replace(“&lt;b&gt;”, “<b>”);

stringbuilder1.Replace(“&lt;/b&gt;”, ““);

stringbuilder1.Replace(“&lt;i&gt;”, “<i>”);

stringbuilder1.Replace(“&lt;/i&gt;”, “”);

Response.Write(stringbuilder1.ToString());

}

</script>

<html>

<body>

<form runat=”server”>

<div>

<asp:TextBox Runat=”server”

TextMode=”MultiLine” Width=”318px”

Height=”168px”></asp:TextBox>

<asp:Button Runat=”server”

Text=”Submit” OnClick=”submitbutton_Click” />

</div>

</form>

</body>

The above .aspx page code shows this approach. The page disables ASP.NET request validation by setting ValidateRequest=”false”. It HTML-encodes the input and then selectively allows the <b> and <i> HTML elements to support simple text formatting.

Now the second tire of security can be brought into the frame by encoding the output to know that the text contains HTML special characters or not.

Response.Write(HttpUtility.HtmlEncode(Request.Form["text"]));   Or in case of URL strings that contain input to the client.  

Response.Write(HttpUtility.UrlEncode(urlString));

As a result, the HTML response stream of the malicious input <script>alert([removed])</script> will look like this

&lt;script&gt;alert([removed])&lt;/script&gt;

This will ultimately restrict the browser to execute the Javascript code because no HTL <script> tag is present any more in the response.The greater-than and less-than symbols are replaced by their HTML-encoded output,&lt; and &gt; respectively.

In addition to this two tire security approach discussed above, we can also use the following countermeasures to prevent cross site scripting as further safe guards.

Setting the correct character encoding:

Character encoding can be done in page level or in configuration level. To set the Character encoding at the page level we can use <meta> element or the ResponseEncoding page-level attribute as follows:

<% @ Page ResponseEncoding=”iso-8859-1″ %> R <meta http-equiv=”Content Type”       content=”text/html; charset=ISO-8859-1″ />  

To set the Character encoding at the configuration level we have to bring certain changes in Web.config file as follows:

<configuration>    <system.web>       <globalization          requestEncoding=”iso-8859-1″          responseEncoding=”iso-8859-1″/>    </system.web> </configuration>

Use white listing approach rather than black listing:

Sanitizing user input by filtering out known malicious characters is a common practice. But we should not rely on this approach because an attacker can usually find an alternative means of bypassing your validation. Instead, your code should check for known secure, safe input. There are other safe ways of representing these malicious characters. For example < (less than) and > (greater than) can be represented as &lt; and &gt; respectively.

Using the HttpOnly Cookie Option:

HttpOnly cookie attribute is supported by Internet Explorer 6 Service Pack 1 and later, which prevents client-side scripts from accessing a cookie from the [removed] property. Instead, the script returns an empty string. The cookie is still sent to the server whenever the user browses to a Web site in the current domain.

SQL Injection:

Secure coding practice in ASP.NET against SQL injection vulnerability should focus on the following countermeasures:

Constrain user supplied input

Before applying any countermeasure at the code level we should be concerned about the potential risk associated with denying a list of unacceptable characters (blacklisting) because it is always possible to overlook an unacceptable character when defining the list. Also this kind of validation approach can be easily bypassed by representing an unacceptable character in an alternate format.

ASP.NET server side validator controls, such as the RegularExpressionValidator and RangeValidator controls can be used to constrain input. Alternatively we can also the Regex class in our server-side code to constrain input.

When user input is captured by an ASP.NET TextBox control, we can constrain its input by using a RegularExpressionValidator control as shown in the following aspx code..

<%@ %> <form runat=”server”>     <asp:TextBox runat=”server”/>     <asp:RegularExpressionValidator runat=”server”                                             ErrorMessage=”Incorrect data”                                     ControlToValidate=”text1″                                             ValidationExpression=”^d{3}-d{2}-d{4}$” /> </form>   If the user input is from another source, such as an HTML control, a query string parameter, or a cookie, you can constrain it by using the Regex class from the System.Text.RegularExpressions namespace. The following example assumes that the input is obtained from a cookie.   if (Regex.IsMatch(Request.Cookies["SSN"], “^d{3}-d{2}-d{4}$”)) {     // perform the database task } else {     // handle exception }  

User supplied input parameters need to be validated before being used in SQL statements. The following data access routine can be taken as an example of how validate user input parameters.

  using System; using System.Text.RegularExpressions; public void useraccount(string username, string password) {     // check username contains only lower case or upper case letters,     // the apostrophe, a dot, or white space. Also check it is     // between 1 and 40 characters long     if ( !Regex.IsMatch(userIDTxt.Text, @”^[a-zA-Z'./s]{1,40}$”))       throw new FormatException(“Invalid username format”);       // Check password contains at least one digit, one lower case     // letter, one uppercase letter, and is between 8 and 10     // characters long     if ( !Regex.IsMatch(passwordTxt.Text,                       @”^(?=.*d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$” ))       throw new FormatException(“Invalid password format”);       // Perform data access operation (using type safe parameters)     … }  

Use parameterized stored procedures:

The following code shows how to use parameters with stored procedures.

using System.Data; using System.Data.SqlClient;   using (SqlConnection connection = new SqlConnection(connectionString)) {   DataSet userDataset = new DataSet();   SqlDataAdapter myCommand = new SqlDataAdapter(              ”LoginStoredProcedure”, connection);   myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;   myCommand.SelectCommand.Parameters.Add(“@au_id”, SqlDbType.VarChar, 12);   myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;     myCommand.Fill(userDataset); }   In the above example the @au_id parameter is treated as a literal value and not as executable code. Also, the parameter is checked for type and length. In the preceding code example, the input value cannot be longer than 12 characters. If the data does not conform to the type or length defined by the parameter, the SqlParameter class throws an exception.

Note: Using stored procedure with parameters does not necessarily prevent SQL injection.Take a look at the following stored procedure:

    CREATE PROCEDURE dbo.RunQuery @var ntext AS         exec sp_executesql @var GO

Now despite being a parameterized stored procedure , this one executes whatever is passed to it.Consider the @var variable being set to:

DROP TABLE USERS;

Use parameterized dynamic sql:

Now if you are not using stored procedure, you still should use parameters when constructing dynamic SQL statements. The following code shows how to use parameters with dynamic SQL statement.

using System.Data; using System.Data.SqlClient;   using (SqlConnection connection = new SqlConnection(connectionString)) {   DataSet userDataset = new DataSet();   SqlDataAdapter myDataAdapter = new SqlDataAdapter(          “SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id”,          connection);                  myCommand.SelectCommand.Parameters.Add(“@au_id”, SqlDbType.VarChar, 11);   myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;   myDataAdapter.Fill(userDataset); }  

Using a least privileged database account:

Your application should connect to the database by using a least-privileged account. If you use Windows authentication to connect, the Windows account should be least-privileged from an operating system perspective and should have limited privileges and limited ability to access Windows resources. Additionally, whether or not you use Windows authentication or SQL authentication, the corresponding SQL Server login should be restricted by permissions in the database.

If your ASP.NET application only performs database lookups and does not update any data, you only need to grant read access to the tables. This limits the damage that an attacker can cause if the attacker succeeds in a SQL injection attack.

Avoid Disclosing Error Information

Use structured exception handling to catch errors and prevent them from propagating back to the client. Log detailed error information locally, but return limited error details to the client.

If errors occur while the user is connecting to the database, be sure that you provide only limited information about the nature of the error to the user. If you disclose information related to data access and database errors, you could provide a malicious user with useful information that he or she can use to compromise your database security. Attackers use the information in detailed error messages to help deconstruct a SQL query that they are trying to inject with malicious code. A detailed error message may reveal valuable information such as the connection string, SQL server name, or table and database naming conventions.

Information leakage: Remember that __VIEWSTATE data can be viewed

The __VIEWSTATE’s Base64 encoding can be easily decoded, and the __VIEWSTATE data can be exposed with minimal effort. Now the attacker can see the information that may be sensitive, such as internal state data of the application.To encrypt the __VIEWSTATE data we have to add the machineKey attribute in web.config  file as follows:

<configuration>

<system.web>

<machineKey validation=”3DES”/>

</system.web>

</configuration>

Somnath has been working as an Information Security Consultant iViZ Techno Solutions,India and have successfully carried out countless assignments on vulnerability assessment, penetration testing, web application security, Threat modeling,PCI DSS Compliance for various Banking sector firms, financial institutions, Govt. organizations, Defense, Software development Companies, leading BPOs and various small-mid-large industries.He holds security certifications like OSCP and CNSM.
Article Source

Use Fewer Lines Of Code!

As neat as that functionality is I have a better idea. User fewer lines of code. That will not only make it clearer, but it will most likely perform better as well. The long term advantages of minimizing the amount of code you use cannot be exaggerated.

Here’s an example and a quiz.

Your boss hands you a new assignment. Shockingly an end user has found a bug in your software. He needs you fix it. It’s not too hard for you to discern the location of the bug. Now here’s the quiz. Would you like to work on a bug in a file with:

1. 488 lines of code
2. 3627 lines of code

Yeah! That’s what I thought. Quantity is not the same as quality.

As luck would have it the file you’re working on has 3627 lines of code. It happens and as usual you don’t have time to refactor the code. Do you think it will be helpful to have 20+ regions in the code?

Not really, regions may have their purpose, but I’d rather have fewer code lines with useful comments.  To be conservative I would say that anymore 4 digits on the line count is too much, personally I’d prefer to keep it below 500, but that’s just me. So do me a favor the next time you have to scroll for several minutes before you reach the bottom of your code, try to see if you can refactor some bits here and there. There’s a lot to gain from doing so.