Software as a Service (SaaS) is the new generation of ASP model designed to reduce the exorbitant costs of specialized medical practice management software. SaaS model is available for all aspects of medical practice management, including scheduling, billing, and electronic medical records (EMR), which are mission-critical for high quality clinical service, business operations, and regulatory compliance. SaaS model extends the advantages of Application Service Provider (ASP) model, which in turn evolves from the traditional Client-Server model. This article briefly defines key concepts and outlines a set of guidelines for SaaS vendor selection.

Client-Server (CS) Model

CS model involves central servers for database and application logic and multiple client modules connected to the central servers via local area network. This architecture allows allocation of significant application logic on the client computer.

Applications architects considering CS model must weigh performance and security advantages against increased maintenance costs. CS benefits stem from local control of application logic and data. CS shortcomings too stem from localizing logic and data because local arrangement requires the user to take responsibility over application maintenance, including data security, redundancy, disaster recovery, upgrades, backups, etc.

The medical practice utilizing CS model must develop in-house expertise and manage numerous services, including

1. Internet connectivity, bandwidth, and routers
2. Servers for Web server software, email, and firewalls
3. Database management
4. Data feed management
5. Capacity management
6. Redundancy management
7. Application upgrade management

Financially, CS models require the software user to make significant upfront investment in hardware and licensing and justify the business case using ROI-based arguments, which make little sense because of software and hardware innovation pace.

Application Service Provider (ASP) Model

ASP model shields the medical practice from high cost of specialized software and data maintenance responsibilities but not from upfront investment in hardware and in software licenses. Early ASP applications were created from traditional CS applications by moving centralized data and application servers to a third-party hosting service provider and allowing access to the application via HTML user interface as an afterthought. The third-party hosting service provider would take the responsibility for application maintenance and data protection.

The medical practice using early ASP model manages two costs:

1. Licensing and monthly support fee to software vendor
2. Software hosting fee to hosting vendor (typically a "pay-as-you-use model")

Software as a Service (SaaS) Model

SaaS model extends ASP benefits from outsourcing of system maintenance to simplified financial responsibilities. SaaS vendors eliminate the upfront costs to medical practice by making the upfront investment in hardware and licensing on behalf of all medical practices using the application.

To make such a financial commitment, the hosting vendor must develop thorough expertise in application maintenance and new feature development. Such a requirement became feasible with recent technology progress in terms of security (128-bit SSL encryption) and browser-based client performance along with AJAX coding methodology. The new generation technology now compensates for earlier CS model deficiencies and justifies network-native SaaS software development by design.

Because of higher specialization, SaaS vendor is able to focus on client business requirements, resulting in more responsive service and higher client satisfaction.

SaaS Vendor Selection

Medical practice in search of SaaS vendor must focus on the following topics:

1. Functionality: Does the application deliver required functionality?
2. Training: Will the vendor provide sufficient application training?
3. Third-Party Application Interface: Does the application work with existing applications already deployed in the office? What requirements must be satisfied if you decide to purchase another application later?
4. Performance: How do you measure application performance? Are formal performance metrics available continuously?
5. HIPAA Compliance: What controls are in place to enable access only on a "need to see" basis? Is every access instance logged using secure mechanism?
6. Service Level Agreement: What minimum service levels the vendor guarantees to the client? What are the penalties for violating SLA?
7. Problem Resolution: Is there a formal process to communicate problem identification and resolution?
8. Data Ownership: Who owns the data?
9. Disaster Recovery: How long would it take to recover from a disaster? Is a secondary data center available 24 x 7?
10. Disengagement Procedures: How long is data available upon severing the relationship? Who is responsible for data transfer to the new vendor?