MedSuite - The Product

Top  Previous  Next

The principals that developed MedSuite have over 75 years of combined experience in the development, marketing, implementation, and support of medical practice management information systems.  The bulk of that time was spent serving the needs of anesthesia practices and billing services.  When we began to design the MedSuite product, we believed that there was a need for a new software product that could address the requirements of large multi-practice and multi-specialty billing organizations.  Many large practices, particularly hospital-based physician practices such as anesthesia practices, tend to handle their own internal billing as though they were a billing service.

 

We felt that the problem with most medical practice management applications was that they simply were not designed for the large billing organization.  We felt that these products were designed for a single practice, but are often used in large billing organizations.  These products generally maintain each practice in a separate database.  As a result, much of the setup information maintained by these products is duplicated and maintained for each practice.  This may seem like a trivial issue to an organization managing a practice or two or three.  However, something as simple as updating CPT and ICD9 codes every year for 20 or 25 practices can become a monumental problem fro a large billing organization.

 

While this may appear to be a statement of the obvious, multi-practice billing organizations tend to use the same coding structure(s) across their client base.  They use the same insurance codes, payment codes, adjustment codes, billing messages, etc.  We wanted to provide this capability while only requiring the maintenance of one set of codes for the entire billing service where possible.  Why make the billing service maintain a complete set of billing messages for each of their clients when a single set will be sufficient?

 

We determined that the best approach towards solving this problem would be to implement a structure in which all of the practices for a billing organization are maintained in a single database and that each billing organization (MedSuite customer) would be maintained in a separate database.  This approach provides the ability to "share" some of the setup information between practices within a billing organization.  Since MedSuite had plans to develop On Demand Software and to become an ASP, this approach also offers the added benefit of physically segregating and securing the data of one billing organization from that of another.  We felt (and still do today) that this physical separation is preferable to simply separating the data for these organizations by using a company code of some sort within a single database.

 

In effect, the billing organization is the client of MedSuite and may be a billing service, MSO, or physician practice.  Nevertheless, the billing organization will use the same coding system(s) for each of their clients or practices.  This model works quite well in billing services and MSOs.  In the past decade, we have seen many physician practices merge into ever larger practices.  We have also seen physician practices "spin-off" their billing office as a separate billing service both to spread some of the cost of billing onto other outside practices as well as to seek additional income opportunities for the physicians in the practice.  So while a physician practice client might not need the multi-practice capabilities of MedSuite at first, having this capability available at the "flip-of-a-switch" can be a huge benefit.