Medical Billing Smart Client

Our client provides comprehensive billing and accounts receivable management services to clients across the USA. This is a highly specialized field in which they had to deal with constantly changing regulations and other factors that are unique to this profession. An old FoxPro application is used to manage quite complex business processes in offices on two continents, with the total number of client workstations exceeding 100. The only viable solution for combining requests for the flexible remote work functionality and such ancient technology was to use Remote Desktop Protocol (RDP). Although this solution was a short term success, it was causing a lot of headaches for the system administrators due to its inherent instability - not to mention various design flaws and non-existing features that were almost impossible to add.

Obviously, the new application can't be a desktop one having in mind all the RDP, speed, security and other problems related to distant office workers. Therefore our client has considered a web solution and has already made an unsuccessful attempt to implement the billing system as a "classic" Web application before we began our cooperation. The attempt failed due to the performance and user interface issues. To put it simply, no Ajax or other technology will enable data entry person to enter hundreds of demographic/charge/payment records every day. The thin client (Web) application model is no longer able to provide the required levels of functionality, performance and flexibility. Users are demanding fast and responsive applications to perform their daily work in a flexible and efficient manner. Another big deal for our client's management are their daily reporting purposes used for varying range of reasons, from controlling workers efficiency to contractual obligation of giving a set of reports to their own clients. They stated that we can expect a high number of reports and their constant upgrading and development due to their policy of satisfying each of their client's doctors in his/her specific desires for procedure statistics, revenue tracking or any other kind of information. Such a broad spectrum of different anticipated report designs, varying from simple pie charts to a complex multi page detailed statistical reports, required a careful assessment of the best model and the most appropriate programming tools used in order to accomplish the most cost efficient way of development.

Finally, amongst the myriad of business specific features and problems our client has, there was one we needed to turn the special attention to. The most important aspect of our client's business is related to sending medical claims to a multitude of insurance companies. There are thousands of claims sent each day. It is of utmost importance that the claims are sent properly following the both government regulations and the specific rules that some of the major insurance companies dictate. For a long time, two different ways of sending the claims have been present in the industry - paper (HCFA form) and electronic (EDI - Electronic Data Interchange). Lately, more and more companies switch to the electronic billing due to a better reliability and faster processing. Some of them like Medicare (the major federal health insurance program that covers most people age 65 and older) even ceased to accept paper claims. One has to understand that an improperly formatted claim (paper or electronic) will result with a payment denial or even worse - all the claims sent in a single EDI file can be denied (the whole file rejected) depending on a severity of the error. This causes significant revenue delays and basically is one of the most important merits when analyzing how successful our client is in conducting their business. All that made us very cautious and forced us to approach this problem with a great care.

After evaluating all the requirements, past implementation failures and current ongoing problems, Mono Software decided to develop the application based on a smart client architecture, since it combines the best features from both Web applications (small footprint, easy automated installation, easy maintenance) and "fat" clients/desktop apps (rich user interface, offline functionality, performance, higher developer and user productivity). Through this design we hoped to reconcile the 2 major problems which are in direct confrontation with each other - a demand for app's accessibility at any time in any corner of the world and the ability for an experienced worker to enter hundreds or even thousands of records per day at a pace characteristic for desktop application users. What that means in practice is a lightweight desktop client app with fast and powerful GUI, which would be installed on every workstation. The client app would communicate with the server (located in the central office) through a classic SSL secured web service.

Medical billing system report GUI

Though this decision may have solved our main problems, it also introduced a couple of new issues. The question arose regarding the installation, deployment and version update of the client portion of the application. One has to understand that many of the distant offices mentioned above have no IT professionals, so the installation process of the client app must be easy and understandable to an average computer user. The update process is even more important due to the expected frequent changes and new versions caused not just by bug corrections and new features, but also by the nature of the business with constant government regulation changes. Fortunately, there was already a growing market demand for a solution to these problems compelling Microsoft to develop a technology called ClickOnce, especially targeted towards this negative aspect of smart client architecture. A quote from MSDN: "ClickOnce is a deployment technology that allows you to create self-updating Windows-based applications that can be installed and run with minimal user interaction. ClickOnce deployment overcomes three major issues inherent in deployment: difficulties in installing and updating applications, impact to the user's computer and security permissions".

The reporting problem was approached with two different development philosophies - one required a lightweight model, where simple, feature stripped, non stylish reports could be designed with a minimum man-hour cost. The other model is, of course, the opposite - a robust design covering even the most exotic client desires and possible appearance peculiarities, but also requiring skilled developers, greater time allocation and highly advanced reporting tools. The EDI billing situation described above required a serious research. Obviously a great deal of coding was necessary to create a bulletproof model with several validation layers. The generated file needed to be correct and properly formatted at any cost. We were hoping to find a third-party solution which would cover at least a portion of a desired functionality instead of reinventing the wheel ourselves.

Being strongly related to Microsoft development tools and technologies, Mono Software based the application on Microsoft .NET Framework version 2.0. Microsoft Visual Studio 2005 was the designated development environment for both client and the server portion of the app. Microsoft SQL Server 2005 was used as the RDBMS at the server side.

One of the reports from the billing system

Another thing worth mentioning is that Mono Software was always devoted to the strongly typed, n-tiered, RAD programming philosophy. After years of search and desperation, we've managed to find a perfect tool which boosted our company's production beyond any of our expectations. The tools is LLBLGen (Low Level Business Layer object relational mapper & code GENerator) by Solutions Design and without it, the development of such a large scale project would be unimaginable. With its help, it's easy to generate the complete business tier based on a database architecture and transform even the most complicated kind of queries to the strongly typed C# code, which provides huge man-hour savings during both the initial development phase and the later bug correction/new features/maintenance phases. LLBLGen outperformed all the other similar tools we tested and remained a strong ground for all Mono Software projects to the present day.
At the time we were starting the implementation, an exciting new technology from Microsoft emerged - WCF (Windows Communication Foundation, formerly named Indigo), designed especially for building and running connected systems. "A new breed of communications infrastructure built around the Web services architecture", as stated at the MSDN web site. Although the web service solution was at the time still quite sufficient for our needs, we decided to adopt this new technology, since it provided a better security, performance and more robustness in general.

As for the reports, considering the two approaches mentioned above, we've found that for our lightweight model, the Microsoft SQL Server Reporting Services would be the most appropriate. It provides an easy way to transform a simple query to a decently designed report in no time. However, regardless of how fond we may be of Microsoft technologies, its reporting services proved lacking in many of the advanced tasks we needed to perform. After assessing several different tools, our choice narrowed down to the Active Reports from Data Dynamics. Its development simplicity, transparence, a powerful event model (which reminded to a simple ASP.NET web page), advanced sub-report options, data binding abilities and many other features started to pay off almost immediately and during the earliest development stages.

The EDI functionality was another story. We had little previous experience with it and were conducting a serious market research for a third party solution. Such a narrow niche assumed quite a high pricing of the available tools, often accompanied by mandatory consulting services, increasing the costs even further. We ended up purchasing and using the FREDI framework by EDIdEv. It is compatible with Microsoft .NET framework and covers the basic EDI 837 (claim filling) generation, parsing and overall processing as well as the EDI 835 (remittance advice - payer response), additionally needed by our client to automatically import thousands of remittance/payment/adjustment/denial entries instead of entering them manually.

Our initial development efforts were dedicated to delivering a bare functional prototype ASAP. Once we got the first feedback from the data entry people, and it being overwhelmingly positive, we knew we were on the right track. They were able to work in the new system even faster than via their old RDP way of work. We also noticed that the improved user friendliness and overall modern design of the app were the additional catalysts, which made them to appreciate the new app even further and want to be trained and start work in it as soon as possible. This was a significant fact for us, since we expected quite a resistance from employees working for 10 years in the same software. Abandoning the old habits and re-learning everything you know can be quite hard and stressful for most people. Thus we expected a fair amount of biased negative feedback and were considering methods on how to differentiate that from the honest user response. To our surprise, the majority of them realized quite soon that the benefits the new system will bring are far greater than the painful retraining process they'll need to undertake.

Patient demographics entry

Of course, not everything went so smoothly at the beginning. Our early performance tests have shown that a lot of data caching would have to be done on the client side, if we wanted to mimic or get close to a classic desktop app user experience. Thus, a special caching model was designed to accommodate this. Basically, the majority of data from the smaller lookup tables is fetched when the user first logs in to the app with the appropriate "wait until the app initializes..." kind of message. Our tests have shown that this provides a far better user experience than caching data on a lazy basis, when it's first needed. The data stays cached on client's computer during the app's lifecycle (until it's closed). As for the large tables (like medical diagnosis codes), which contain thousands of records, they could not have been cached without a significant impact on the app's performance. Thus, another model was designed to tackle that and is closely related to the GUI elements that data entry people use for input of such information. The model reminds to the AJAX powered UI elements from the web development world. For example, a user should type the first couple of letters of a diagnosis code that needs to be entered and only a small, limited recordset of codes that begin with those letters will be fetched, prompting the user to select the correct code amongst the ones returned.

A typical patient statement

The examples mentioned are just some of the many techniques and solutions applied in attempt to facilitate user's work experience and make them unaware of the fact that they are not working in a true desktop or an intranet application. Sure, during a low or no connectivity they would certainly become aware, but there is no architecture or model which would compensate that, except maybe a disconnected smart client model, which was not an option for us due to the nature of our client's business.

Our decisions regarding the reporting proved to be good, though our client forgot to tell us about an important requirement. The initially agreed report output type was PDF, but we eventually found out that the EXCEL is just as equally significant to them. Luckily, our chosen reporting tools had decent enough EXCEL exporting options.

The FREDI framework mentioned above saved us some time and resources, though not as much as we might have expected. The whole package covered the basics, we still had to add several layers of logic on top of it in order to successfully tie it to our database architecture and handle all the government regulations (HIPAA compliance) as well as the specific insurance or a clearinghouse (a billing intermediary) dictated rules. Being aware that there is no "magic wand" solution, we still appreciated that we were relieved of the raw EDI file processing and kept control over the crucial validation and formatting options.

The new application increased productivity, improved security, facilitated users' daily tasks and created solid grounds for the future development of the new advanced features. The app's availability 24 hours a day to anyone with a decent internet connection made the whole business insensitive to the worker location, enabling managers to move certain portions of the company to distant, more profitable locations. "We can finally plan our offshore operations without any technical shortcomings and start expanding our business on account of that. I'm already looking forward to our increased revenue." one of our client's management officials pointed out.

Charge ledger screen

Furthermore, our client was able to attract more customers on account of the flexible reporting ability. Generating non standard, doctor specific reports, it was able to offer a more personalized approach to the business. For example, some doctors would care about the procedure statistics based on the patient's age, others would be interested in the ratio of the pain management cases versus other cases, etc.

The careful planning of the electronic billing programming infrastructure and the layered approach minimized the claim denials and revenue delays. It also provides the ability to easily change the validation or the formatting rules, which makes the whole business more resistant to the constant regulation changes and independent of the large clearinghouses and their possibly unfair terms. In other words, if our client is not happy with a clearinghouse treatment, it is easy to switch to another clearinghouse and quickly implement its accompanying rules.