(Resent as the original mail was witheld since I had sent it from another e-mail address)
I wonder if there could be more clarity on the proportion of work done in the task of porting VistA on Cache to Linux & GT.M. Perhaps someone could educate us, lesser mortals, on what was the total work content in the task of porting VistA Cache to OpenVistA/GT.M. Perhaps a classification of the areas of work needed and the work actually done would be very educative. I feel that chunks of work may have been left out. Perhaps someone more knowledgeable could correct me if I am wrong. One positive sign is that Mexico appears to have implemented OpenVistA. But what they have really done is not fully clear. They are not exactly shouting from the housetops. Others are! But there are gnawing issues that are unanswered. The first is that most successful vendors, from Medsphere to Elsie Casugay, seem to work exclusively on Cache. Medsphere was actively involved in the porting and so lack of familiarity or experience with GT.M cannot be an argument. It is sometimes claimed that it is because Cache has a strong branding, or that there a strong customer preference, or are there commissions to the suppliers to work on Cache? I suspect that the real reason is that some of the key functionality of VistA has not been reproduced on the GT.M version. Because having a free database like GT.M enables a significant saving on cost and competitiveness. And we all know that GT.M is as stable and robust a Cache, Secondly I wonder what is the agenda of the exclusive OpenVistA R&D coding worshops. Is it to address some of these issues that were left out at the OpenVistA porting exercise? Thirdly there are issues, which we directly face. My colleague Usha tried unsuccessfully to get an answer to a specific question on Hardhats on the problem of HL7 connectivity from an OpenVistA installation we had done on Suse Linux using the latest Pacific Hui version 3.0. In the case of the Cache implementation of VOE, the TCP/IP listener could be setup, by configuring the logical links, and we could send and receive HL7 messages between two Cache implementations. The same setup procedure does not activate the listener in GT.M. According to the output of Netstat on the VistA server, no service seems to listening on the corresponding port. I would appreciate if someone who has implemented HL7 on OpenVista could come forward rather than make a speculation that it must have been done in Mexico. The reason for my special interest is that those of us who are not experts on VistA but believe in its potential will benefit considerably if the correct status of OpenVistA is known. If there is transparency, we will not need to struggle on issues, which we know have not been addressed and spend our time based on assumptions that are incorrect. I suspect that some of us may be looking in a dark room for a black cat that is not there. Joseph Puthooran Edgeware Technologies (India) Pvt Ltd E-537 Greater Kailash II New Delhi 110048 India E-mail: [EMAIL PROTECTED] Phone: +91-11-55633899 Mobile: +91-9810284528 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
