Open Dental Forum

I currently support a client that runs a very expensive, very bloated, very frustrating to use/maintain/work dental software (this client is an orthodontist, btw, and the software will remain nameless for right now). The company in question, doesn't support this, doesn't support that, and has VERY specific hardware requirements on many things, and it's just not working out. Here's some of the things (I'll try to remember everything I can here) that we have/need:

1. ( and this is the big one ) MULTIPLE OFFICES...the current software handles this horribly, we have to RDP into a remote server to use this software. The server is not handling this very well, even though it's a pretty beefy machine. It would be so much better if each office could work individually then the data could somehow synchronize...
2. Printers/scanners (these are all network printers/scanners) however scanning is not supported on RDP, so we have to scan locally then import the scanned file later to the patient record. Very time consuming and frustrating for the user.
3. USB credit card swipers. We have to use a very specific brand which is the only one supported. This also is not supported via RDP.
4. Image capture (we have a Sirona x-ray machine) also not supported via RDP, have to locally capture and import.
5. Fingerprint readers (input and then for signin later). Not supported over RDP. We have a signin machine and this method for HIPAA compliance.
6. Credit card integration stinks. The software works as POS, but "calls" a third party application, which then you have to interface with that application to process batches. Very, very klunky. Does OD have a better method?
7. Printing, well printing over RDP has been spotty at best.

That's all I can think of in that regard for now. I'm sure there's more I'm forgetting so I may post back with more information. The Dr. thinks (or at least did when he bought it) that this software was the best thing since sliced bread, but we've had issues with it since day 1.

Oh and here's a little background on our machines, Windows Server 2003 R2 SP2 servers, and Windows XP Pro clients SP3, Office 2003 SP3. Nothing out of the ordinary here.

Thank you.

1. See http://www.open-dent.com/manual/multiplelocations.html If RDP is slow with that software, it will also be slow with ours. If you look under the daisy chain replication option on that page, you will see local servers at each clinic with a synchronization mechanism working continually behind the scenes. It's near real-time and works quite well as long as you are confident that you can get the synchronization running again if it goes down.
2. This would be a non issue if you don't use RDP.
3. We don't care what brand you use.
4.
5. We don't yet support fingerprint readers. We also don't have a sign in list for the front desk.
6. Our credit card integration seems to work fine. We also call another program running on the local machine, but I've never heard complaints about it being klunky. You do interact with that other program to look at batches, and so on. Not really sure what kind of improvement you had in mind. Maybe the one you're using is just poorly designed. I don't think the basic approach is bad.
7.
Most of your problems seem to be related to the RDP. I can understand that. There isn't going to be a perfect solution, no matter which software you go with. There are a few web-based software programs out there which would simplify and centralize the basic data. I don't think they are as powerful for other things. I think OD is the most future proof software with the best chance of providing an appropriate long-term solution for the office in question. But make sure they can live with the missing features listed at the bottom of http://www.open-dent.com/manual/orthodontic.html

Daisy chain replication sounds exactly like what I wish we had right now in our current setup. Unfortunately the current software vendor is too lazy to have such a feature...they say it would require them to re-write the app from scratch (I call BS on this one).

The issue with our credit card based software, in a way, again relates to the multiple offices. There can be only one database for the credit card software, so therefore at least 1 office has to use the dental software as a POS which then "calls" the merchant software, then at the end of each day, we have to fiddle with the merchant software to close out a batch (and the merchant software has its own requirements, has to be on a machine that's on 24/7, static ip, and no terminal services, and did we mention it's not supported installing it on a server? yeah, makes a lot of sense, right??)

What's the timetable (if any) for fingerprint scanners/sign-in-front-desk, just curious. Maybe if we lose that but gain not having to run (or lack thereof) everything over RDP as we are now the gains will outweigh the losses.

It took a great deal of effort for us to add daisy chain replication. They might not be exaggerating. Merge replication is really tricky because you can't let any foreign keys collide. What we do is to use very large and random keys so that the risk of collission is negligible. We also partition the range so that even that small risk disappears.

Our merchant software runs a server program on one computer in the office. Any old computer will do, such as the one at the front desk. I'm not sure how using RDP would complicate the merchant software issue.

I'm sorry, I can't give you a time estimate. I can say with some confidence that a list that uses a screen and mouse is higher priority than fingerprint scanners.

RDP is much improved in Windows 2008 Server. You don't have to deal with having 2 desktops, you can use TS RemoteApp and it appears as if the program is running locally. If you have .NET 3.0 on the client and use RDP 6.1 printing isn't a problem - all printers installed on the client show up without having to add the drivers on the server. It is a little slower to have the printing redirected than local though. You can also make the an app web-based using TS Web Access - haven't tried that yet though. We're still in the early stages, but so far it's working well for us.