Client too old message...

I was running client 202 on several machines when suddenly they all gave the error that the client was too old. It was obvious this was date-based, as I had changed nothing about the server, and rolling back the system date on Windows caused the error to go away.

This is particularly difficult to deal with as I do not have direct control over one of the client machines that is used for scheduling appointments. How can I know what date this will happen for a particular client, and how can I prevent it from happening in the future?

Anthony

We have a client installed offsite that is used solely for scheduling. We do not have direct control of this computer, and forcing an update to the client every 3 months seems a bit arbitrary. Is there a way to disable this time limit?

So then are client upgrades to be required at least every 3 months?

While I respect the pain caused by dealing with users running ancient clients, we are trying to deploy this in a clinic that requires a client on a hospital computer for scheduling. Requiring hospital IT to upgrade the client on that machine every 3 months regardless of our actual need for an upgrade is painful. Do you have any ideas for a workaround that would eliminate/minimize this need to involve the hospital IT staff?

I guess I should start of with Kudos for a remarkable software package.

I am the rehab physician in the US that came in one morning and noticed that I did not have easy(aside from a flatfile export of the database) access to my patient records. My practice is new and small so it wasnt a big deal but going forward the thought that for any number of reasons, ( i lose internet connection for months-the practice is in rural america, Graham moves onto to bigger and better things in his life, ....) synapse development stops or is not updated, then every physician using Synapse would be left without easy access to their patient records in 3 months because their client "expired and is too old". At some interval there should be non-expiring client that one could revert to in a crunch, otherwise the thought of being locked out from your data is likely a deal breaker for anyone that evaluates this EMR.

I understand the issue with supporting older clients/servers with fixes in the updated versions and I would support a policy that requests any software support require the latest server/client combination. Perhaps each post should start with Client ver XXX, Server ver. XXX, and your bot can autorespond to update to latest ver ZZZ for the latest bugfixes or prior to posting


However, having a non-expiring client version would offer some safety net for the physician to get to the data.



issue #2

"it's just a click on a button on the upgrade screen to update the client "

Anthony is working with me to implement your product. The upgrade is easy in my office where i have full access to the C:\ drives. However, I also use the client on the hospital computers where there are plenty of security measures in place that do not allow write access to any drives thus I had to obtain special permission and have the IT dept install the client on 2 particular machines. The easy upgrades are now not so easy because IT administrative priveleges would be needed to download the new client and rename the file synapse.exe. Thus every 3 months i will now need to call IT out to my department and have them login and go through the 1-click upgrade process. A non expiring client would also remedy that problem at some static point in time. Rather than have you set the timeframe of making me call IT every 3 months, it would be better to allow me to decide at what point i cant live the existing bugs and call IT to install the updated client version.

I hope I don't sound too demanding because I realize, "hey its free", and nobody is forcing me to use your product. I just want to make sure I understand the limitations to the tools that i am using so that I can make the best decisions regarding the use of the tools

Thanks for hearing me out. I look forward to anyones thoughts.

updating was successful. Thanks. The usb key idea is interesting although the problem previously identified of incorrect mapping of folders would need further evaluation in my setting.




On a separate note is there a field for "copay" or is it relegated to the "miscellaneous" tab-field 1-4?

-A

The front office should collect that amount from the patient at that visit. Depending on the insurance carrier each patient would owe a different amount. The office staff checking-in or out the patient would need to look that up that value somewhere and "attempt" to collect that amount.

"
If you run it from a USB drive, then all the paths will be incorrect .. for postscript, etc.

But you will be able to see your patient data, just may not be able to easily print."



<hr align="left" size="1" width="25%" />Graham Chiu
Beta Downloads"

I appreciate people taking the time to help... and thus search in order not to ask questions that have already been answered.thus i was referring to your post quoted above. Unfortunately, i do have to generate physical printouts for charts in particular formats so a roving synapse client may work in the hospital... but i still need to give though to whether i would need immediate printing availability at the "wokstation of the moment"- the answer is likely yes.