Open Dental Forum

We are finally done with the first bit of programming for the web version. It's not much, but I did want to show it so that people could see the potential and so they would know we were still working hard on it.

This is entirely HTML/CSS/JavaScript. There are no plugins involved (like Flash, Java, or Silverlight). Everything has hover effects. Events fire immediately, and there are no page reloads when things happen. Instead of a page reload, the JavaScript immediately alters the DOM on the current page. Any data calls will be done asynchronously in the background, and that part is what we're working on next.

One interesting benefit of a browser is that the user can change the magnification of the entire program without any problems at all. Also, everything is designed with more of a flow pattern than a fixed layout. That may result in some less efficient layouts sometimes, but for the most part it will allow more flexibility.

Hi Jordan and team,

Good progress! I like the browser capabilities as much as the next guy/gal. One thing I would like to bring up: inherent browser insecurities. Cross-site scripting, javascript hijacks, history tracking, etc. Scared the heck out of me whenever I needed to use the browser on the server. What's your plan on minimizing known/unknown browser security holes? Make the browser use intranet addresses only? If so might as well use the standalone program.
Also, perhaps add an option to turn off browser capabilities if the customer does not need/want it. I would guess this will use IIS? If so if IIS is not installed, the browser portion wouldn't work, so it wouldn't matter.

This wouldn't be something that you would accidentally turn on. You would need to explicitly set it up on the server. Cross-site scripting isn't really an issue here since all the data will come from the same server as the program itself. I think it would be very unusual to have your browser security settings allow anything else. If the program needs data from somewhere else, it will need to go through the original server to get it.

Keep in mind that we are writing this program in full Java, and it gets compiled to JavaScript. In other words, the client program is very smart. We can easily build in logic so that when the user logs out, it takes them back to the login page, clears history, dumps their saved credentials, etc.

so is the data still hosted locally or is it in the cloud or both?

Either, but not both.

This web version is still for doctors and staff only. What do you think about extending it to the patient? What I mean is the ability for new/existing patients to check on when a particular time slot is available so they can request that time, check when their next appointment is going to be, check their balance, etc. I think most dental software are geared toward the doctor and staff, while neglecting the patient entirely. OD's patient kiosk / web forms are steps in the right direction. But the web version in patient mode would be just...awesome. Of course I am not a programmer so I don't know how difficult it can be. Just a suggestion.

Of course, but it would be a separate program. We've clearly tried a number of approaches to patient portals over the years. I'm hoping that the technology we're using for this web version will be useful for our next attempt at a patient portal as well.

This is SOO cool. Its like Outlook Web Access with Microsoft Exchange.

I don't think most doctors would like the idea of patients tinkering with schedules. The portal part is nice for patients to be able to review payments, procedures and past appointments. A read only copy of the schedule which can be viewed by the patients ;instead the real one -will probably do the trick. Some logistic can be applied to a form that can search for provider availability and procedure in question; and then suggest a couple of openings. If the server is hosted at the office, I would assume that security certificates will have to be implemented to secure the online transaction. I don't think that self signed certificate will do the trick.
Jordan, I do have a question in regards to OD-WEB (umm I like the acronym) to bridging with digital sensor and imaging software ? Are you planning support for that on this version?

" Care To Share "

We're keeping it in mind, obviously. But I think it would come later. We would want to release it as soon as we had something workable rather than waiting. On the other hand, this is very different than building a program from scratch, because we already have this incredibly rich database, and we already have working examples of how it's supposed to behave. So I really think that we can add features very quickly once we build the foundation. The foundation is going to take time, but it's a great investment of our time even if we have nothing to show for it for many months.

This is really good feature.. I think you should hide the IE menues and URL and etc.. to have the proper effect just like the regular version... as now we opening up the IIS on server security will be essential... How about session timeout?

How is the progress on this project? Are you close to beta release ?

No. We've basically been too busy with other things. It's too complicated to explain. It remains a critical part of our growth plan, so I do expect that you'll be seeing something "soon". I put soon in quotes because that could mean anything from weeks to years. There's just no way for anyone to know the timeline at this point.

This is great! Sorry if you have provided details earlier and I missed that somehow, but some basic questions

1) does this mean no more client installs?
2) no need to have IE/windows for clients?
3) Is the server going to be a J2EE appplication and be able to run on Linux?

Thanks for this exciting news.

1. Yes. The "client code" does still need to download from the server, somehow. The usual trick is to do that in the background while you are busy logging in. But no install, and this is the main motivation.
2. True. It would run in any browser on any device.
3. The server will be a C# dotNet application because it needs to leverage all the existing C# code that we have already built. Our server installer and instructions will all assume Windows, not Linux.

2 out of 3 is not bad

I like the direction opendental is moving towards.

Good luck and thanks for sharing...

Will going cloud complicate a new reporting engine?

A little bit, but not really. Modern reporting engines all seem to work well in a web environment.

How is this going? I am just curious.

Justin Shafer wrote:How is this going? I am just curious.

We're getting the framework massaged with our smaller web projects right now. We've converted over Mobile Web, Patient Portal, Web Forms, and introduced the new Web Sched all using the new framework that we wrote that is geared towards the full web version of Open Dental. After a few more useful enhancements to these projects, like accepting patient payments from the patient portal, well start working on the web version of Open Dental. I'm pretty excited for it and I'd imagine well see a 'lite' edition of the web version some time in 2016-17 (assuming EHR doesn't come back with a vengeance).

Very Cool!

If hosted locally will we be able to use ssl?

willcipriano wrote:If hosted locally will we be able to use ssl?

If you are referring to HTTPS or "HTTP over SSL" then yes. It is actually a requirement for all of our eServices. They will not work if you try to access them via HTTP.
http://www.opendental.com/manual/encryp ... ansit.html