Let me say before I even start, that I know I am not an expert, but this is what I have learned and, hopefully, it is correct, from my time with working with VistA on the two platforms.
I see no reason at all that you cannot be supported remotely and the contracting I am referring to is to help correct what sound like relatively small problems with running VistA on GTM/Linux. If surgery can be done remotely, surely computer support of virtually any sort, even hardware support, is not impossible give some ingenuity. The GT.M folks, like those with Intersystems, already provide support in many areas of the world quite successfully. Besides, I doubt it is GT.M that is the problem. Because of the way VistA is programmed, the problems are almost certainly in the infrastructure routines which are the ones that allow VistA to work with varying operating systems and devices. They are likely VistA issues, not GT.M issues. You need to identify them and if the Hardhats don't give you an answer, you will likely only need to hire one expert for a limited time to fix them. VA programmers will likely fix them eventually, but it might not be on your timetable. VistA is heavily used in VA hospitals with Cache and almost every stone has been turned for their particular platforms including their particular brands of machines with the particular version of the operating system they are using. Now you are turning stones for VistA used with GT.M/Linux that have either not been turned or solutions have not been shared for any number of reasons. The work done by the Hui project and others has been wonderful for the community, but VistA is vast and to expect those who have contributed to have turned over every stone is unrealistic. In addition, we are always pushing the envelope, using different flavors of Linux, different machines, etc., than they have used. Despite the heavy VA use of VistA, the community has managed to turn a few stones the VA has not even in their relatively controlled environment and the cooperation in solving the problems identified between the folks at the VA and those in the community outside of the VA has been wonderful to see. As the use of VistA increases outside of the VA, more of these sorts of problems will be uncovered. Have you a list of problems that you have identified where Cache/Windows works fine and GT.M does not? Perhaps you should catalogue them for us so we can seen what these problems are you are referring to. So far I recall one HL7 issue that you have identified where Cache/Windows works and GT.M/Linux does not . As I understand it, the GTM/Linux specific infrastructure routines that deal with devices are known to need improvement. I think that dealing with devices is a perennial problem with any system and any program. A side by side comparison of differences in the behavior of VistA between GT.M/Linux and Cache/Windows would almost certainly vastly speed up the process of fixing the problems and keep the cost of hiring an expert down. Someone with expertise could probably solve them very quickly given that sort of presentation. I found that to be true when getting help from volunteers helping to work through the porting of he VA Demos from Cache to GT.M. One I asked about one just the other day turned out to be due to the terminal that I was using - not a fault of GT.M. On Saturday 03 June 2006 10:52, Joseph Puthooran wrote: While responding to people like Nancy or Kevin, I do so with a great degree of reverence and admiration. They have set high standards for transparency and helpfulness that many of us have greatly benefited from. You have infinite patience and no newbie would ever feel uncomfortable interacting with you. My programmers and I have found your responses so very helpful. Others in the Hardhats community are not far behind and we are indeed grateful. But there are issues that we should not shy away from discussing. Nancy spoke about the pros and cons in choosing Cache or GT.M. I would always prefer GT.M as most of my target clients cannot afford expensive systems. But I struggle to understands the why there is an almost exclusive preference for Cache by most vendors there. But what are these pros & cons in the context of VistA? The robustness of GT.M is unquestioned, but the issue here is the completeness with which the Hui did the porting. In the final analysis, would it prove cheaper to use Cache rather than the free OpenSource GT.M, if there have been serious problems with the porting. If the limitations are documented, it may be easier to better understand the pros & the cons. If it proves to be a truly comparable solution technically, I am sure that people will be willing to buy support for GT.M. The only problem is that while Cache has a dealer in Delhi, GT.M as far as I know will need to be supported from the US. I am sure that once we do get some clients using GT.M, Bhaskar may not mind visiting his old homeland once again. Perhaps he could help build the really Indian "Indian Health Service" here. I am in full agreement with Nancys that we will need to .contract with someone with a great depth of expertise in this area . . But with the ground realities in India and the kind of prices that are acceptable to the Voluntary hospitals that I am targeting, such support will have to be heavily be complemented by our own local team. I am working on building such a team and when we do get an order, we will certainly contract with some of those who have so generously helped us. __________________________________________________ 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 -- Nancy Anthracite _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
