Technology

MedSuite uses the ASTA communication architecture for Windows-based applications. The architecture of the MedSuite's On Demand Software is enabled by two fundamental technologies that we believe make the MedSuite's On Demand Software different from other enterprise medical billing and practice management applications.

What exactly do we mean when we talk about n-tier (or multi-tier) applications? An n-tier application is simply one which has the capacity to run on multiple physical machines. The ancestor of n-tier application technology is the client/server application technology where there is delineation between the client and the database server that is most likely located on a server machine on a local area network. These applications are commonly called "fat client", as most of the business logic for the application lies on the client side.

The evolution of n-tier was spurred by the realization that performance, scalability, deployment, sharing of functionality and application maintenance could be significantly enhanced by dividing application functionality into any number of separate tiers. This allowed applications to be developed where each key part of the business logic could be encapsulated in its own process. This provided the ability to deliver real "thin clients", as most of the applications functionality could be stripped out of the client to be located appropriately on a server or other machine visible to the client. Thus, the 'n' in n-tier simply denotes an undefined number of tiers. The most common manifestation of the n-tier paradigm is the 3-tier model. This entails the following logic:

While the above example is a very simple explanation of the paradigm, it is adequate to explain the concept – in reality; some program functionality may be shared between tiers.

So what is happening in each of these three tiers? The client application manages the user's interaction with your system. It includes all of the screens and dialogs that allow the user to interact with your program. The application server (or middle tier) includes the actual business logic – this tier provides the main functionality. The middle tier (as its name suggests) manages and controls all interaction between users and the database tier. Finally, the DBMS/database tier includes your actual data and the processes required to manage that data.

Scalability is a significant issue with n-tier systems. When we developed MedSuite, one of the issues we wanted to address was that we wanted to ensure that server resources are properly managed. MedSuite optimizes resource usage based on expected client utilization levels. Servers can automatically expand available connection resources without user intervention to cover peak usage requirements without the need for programmer intervention.

MedSuite is easy to deploy. MedSuite uses TCP/IP for the transport of messages between tiers, requiring no additional communication protocol and no component registration. There is no need for COM/DCOM or other such technologies. MedSuite also provides the ability to automatically update client applications to the most recent version. The server keeps track of the most recent version of each client application. At login, if the server detects that the client is running an older version of the client application, then the server will stream the latest version back to the client.

MedSuite utilizes high performance encryption and access control methodologies to its servers. It uses certificate based encryption, unique session keys, firewalling, message switching and logging. It provides unparalleled protection for your servers and your data.

The World Wide Web ("WWW" or "the web"), and the servers and browsers that make it work, are fantastic and highly useful pieces of technology. But like all tools, the web has appropriate and inappropriate uses. Whether you entrust your business to a technology like the web or a technology like ASTA is a question of appropriate use.

The following table contrasts browser-based applications and the MedSuite's On Demand Software:

	Browser-Based	MedSuite On Demand
Appropriate Use	Lightweight Applications. Web is ill-suited for data driven, enterprise-wide business applications	Heavyweight Application. Specifically designed to be a data-driven, enterprise-wide business application
Protocol	HTTP - Stateless and therefore connectionless; Cannot "push" data to a client	Maintains state and connection; Can "push" data to clients
Interface	HTML - Appears to be rich, but is actually lacking in both features and development tools.	Rich feature-set built with state of the art development tools.
Java / Active-X / etc.	Deployment is problematic and complex. Often lose platform independence offered by browser	Not necessary

We believe that the classic web architecture - a light browser, a protocol like HTTP, and a server – is the best way to handle many lightweight applications. A website is an example of an appropriate use of this technology – the web is great for presenting read only data. Even though the technology used by the MedSuite's On Demand Software can (and does) perform this task, it is handled well by the WWW and is the better choice for publishing static pages of information. But while the WWW is good for simple data, we feel that it is a poor choice for implementing complex applications, even with Java or ActiveX. The web seems particularly ill-suited for data-driven, enterprise-wide, business applications.

The problem with the web is fundamental to it's architecture and manifests itself the protocol called HTTP and the fact that this protocol is stateless. A "stateless protocol" is one where the connection is not maintained. Put simply, the web can't "push". Clients can ask the server for information, but the server cannot send information to the clients that clients did not specifically ask for. For instance, a customer might trade stocks using a browser on the Internet. But the brokerage notifies the customer that their stock trade has occurred by sending email. This is the result of an architecture built on a stateless protocol; the server cannot update the browser. While this is not a critical problem for a casual surfer, it is unacceptable in a business environment.

The second problem with the web is the limitations of Hyper Text Markup Language (HTML). At first, it appears that the web has a rich interface - look at all the rich text, images, video and even audio! These media can be readily delivered in business applications. They simply haven't been. Why? Probably because most businesses are more concerned with basic commerce than entertainment. Hopefully, as a result of the web, "regular" applications will become more lively without sacrificing their usefulness. But despite the varied media riches, HTML is not practical for business tasks. HTML has inadequate database support and interface tools.

Java, ActiveX and other embedded browser-based technologies have their own problems. Essentially, once program code other than the browser is deployed on the client, you are faced with significant deployment problems. In addition, the platform independence promised by the browser-based application is lost with Active-X technology in particular, but also to some degree with Java and other technologies.

The MedSuite's On Demand Software was designed from the ground up to be use an N-Tier architecture. This isn't an academic issue, it's a very practical one. At MedSuite, we wanted to take the best features of the web and balance them against the needs of medical practice administrators and executives. We wanted to take the best features of the web and then add the capabilities that are critical to practice administrators and executives. We wanted to purposefully avoid the "bleeding edge" pitfalls of other technologies. We wanted to deliver a thin client application that can be centrally controlled, installed, and upgraded. We wanted the business rules of the application to be maintained at a central server. We wanted to use a proven near-universal technology standard like TCP/IP and minimize the bandwidth requirements of the application. We wanted to develop an application with a small "footprint" that would run well on older inexpensive PCs even over a dial-up line.

We believe that the MedSuite's On Demand Software meets all of these goals and more!