I concur wholeheartedly with Terry regarding the need for an "integrated system" and the lack of academia's appreciation of same. However, in those early days, such oversight was not limited to academia. The commercial developers failed to see the need for (or have the skill to produce) a clinical component of the integrated system.
My first experience was also in the 70's (Went live 12/1970) with a service bureau, which, though on mainframe, was never able to create any clinical component or print an insurance form. By 1978 we had our own minicomputer and gradually filled in the gaps, over the next 5 years. All this time we watched the budding development of the MUMPS language until finally in the late 80's we were able to move all our data to a PC running VA Kernel/FileMan. Today this is migrating/upgrading to VistA. Points (admittedly opinionated though with strong evidence): 1. Integrated system is essential to managing any clinical package. 2. The Accounts Receivable (AR) isn't so difficult to do in VistA 3. There is NO NEED of AR multiple pricing scheme- see comment below 4. Electronic media claims benefits the claims processor 5. Electronic media remittance benefits the provider 6. Electronic media exchange benefits the provider (and patient) Comment: AR - There have been repeated claims and requests in this forum indicating need for a multi-pricing system. My experience in programming electronic claims and remittance is this is a misnomer. Such interpretation misses the point that the agreement with the claims processor is for payment accepted- not prices charged. The only pricing scheme of merit today is the resource based relative scale RBRVS created by Hsiao, et all (link 1 below) and more recently described in Medical Post(link 2 below). All contracts I have negotiated have remittance as the base - not pricing. What this means is one does not require multiple pricing but agreeing on a specific remittance accepted from various companies and claims processors. When the logic shifts to remittance management, claims management is simplified. If everyone adopted RBRVS there is only one number that needs a change to make adjustment to one's entire fee schedule - that of the conversion factor (which impacts every fee equally). Imagine the efficiency of changing 10,000 fees with changing just one number. Electronic Media Remittance (PAYMENT) management is via "exception reports". Entry errors disappear. If one uses electronic remittance the only payments that need human eyes are those out of compliance and generated by exception reports which print a list for evaluation and action. Sorry for such a long post. However, I think the point about AR being a VistA weakness overstated, due to noted misconceptions. Links: 1. http://www.cms.hhs.gov/about/history/hsiao.asp 2. http://www.medicalpost.com/mpcontent/article.jsp?content=/content/EXTRACT/RA WART/3823/05A.html Thanks, thurman > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:hardhats- > I'm not familiar with all the components of VistA, however, as the > project leader of the COSTAR project back in the late 70's (project > collaboration between NIH, DEC and the Laboratory of Computer Science, > MGH), I learned a few things about private practice software systems > that have not changed over the years (they are burned into my memory > :-) > > Just a couple issues to make the point: > > 1) MGH thought the greatest asset of the system was the Medical > Records component. We told them that was great, but only part of the > picture. To be really viable, the system needed an integrated > financial package (A/R, etc. > as a part of V1). Does VistA meet the requirements of a private > practice, does it have a usable financial package and all those > components required of these environments? People like Kevin are in a > position to make these assessments. > > 2) DEC wanted to advertise COSTAR as a "turnkey system". It didn't > take a genius to figure out that this concept required a superb > installation process (not just software) that essentially "dropped in" > to make it financially viable for DEC. Is VistA ready to drop into > these environments or will it be a long, drawn out process? > > These are not criticisms of VistA, I'm just pointing out a couple > lessons learned (yes, there were more than a couple). > > As a commercial venture, like so many, DEC eventually backed out > because it became obvious that it was not going to be profitable for > them, MGH shrugged it off and NIH went on to whatever... > > To make VistA successful in this sector requires lots of planning and > work. > If you ignore history, you are bound to repeat its mistakes... > > Terry L. Wiechmann > www.esitechnology.com > 978-779-0257 > ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
