Clear.Dental is a complete suite of modules that do whatever tasks that are needed in a general dentist’s practice. If any feature is needed in a dental practice, it would be added to Clear.Dental.
Anything that can already be done via another open source program (like web browser or image editor), anything that has to be done by an outside vendor (think credit card payments), or anything outside of dentistry.
Yes. It is one of the many reasons why Clear.Dental had to get a more modular design.
Because dentistry is full of proprietary and opaque software that do not allow doctors to know how their own software works. Clear.Dental works to fix this issue by making as much of the software stack open source as possible.
Because the UI has to be built with touch in mind and the backend was built with a UNIX filesystem and git in mind. Also, the radiographs drivers have to be written to work with Linux.
OpenDental has no plans to redo their whole UI touch based. OpenDental also doesn’t support Linux. OpenDental also has zero plans for radiograph acquisition. Therefore, outside of a few billing functions, there isn’t much to work with OpenDental.
Then it would defeat the whole point of making an open source software stack. This project is all about reveling the secrets that are slowing down the dental industry.
By offering turnkey services like remote hosting, phone support and even custom UI support.
A Raspberry Pi 4 with 4GB of RAM, and 32 GB of disk space running on a UNIX based system like Linux.
The sky's the limit. You need to get a triple monitor setup in order to fully utilize the patient entertainment features; that requires a proper discrete graphics card. It is highly recommended to use a GPU from AMD and to avoid anything from Nvidia until they provide open source drivers.
For the front desk, I built two PCs with an AMD APU. The combination was AMD Ryzen 5 3400G + 8GB RAM @ 2666 + GIGABYTE A520I AC. For the Ops, I built one with AMD Ryzen 3 3100 + 8GB RAM @ 2666 + SAPPHIRE PULSE Radeon RX 5500 XT and two that were built with AMD Ryzen 3 3100 + 8GB RAM @ 2666 + Biostar Radeon RX 550 2GB.
In theory, yes. For Android, macOS and iOS, more testing will need to be done. For the *BSD, the issue will be with making sure the GPU drivers work properly for that OS.
Window’s NTFS filesystem doesn’t support transparent symbolic links which is used by Clear.Dental for many performance enhancements. The Windows OS is also closed source with defeats the purpose of Clear.Dental.
I did a writeup over here.
Because it's easy for me to read, debug, and for me to teach other people to read.
If a conflict were to arise during a merge, the old data from the previous commit is simply rejected (using strictly "theirs") and is overwritten with new ones.
Almost. The data will still be there via the git repo’s history / log. If two addendums to a .json file at the same time, whichever is first gets “lost” in the git history and the second is properly added in.
It can be done with a fair amount of work. I am open to patches ;-).
Because humans can forget to unlock files. Having any file locked in a clinic is always annoying and I wanted to prevent that from happening. And having a script to unlock the patient after use doesn't always work.
But if that drive goes down, you can’t access the data! But yes, you could just have a single server host all the files but you are now reliant on the network working perfectly all the time.
If the internet goes down, you can’t access the data!
In other practices I worked at, once every few months. In my own practice, the network has an uptime of more than 10 months. I am more obsessed with the idea of being able to access data no matter what kind of failure happens.
Then there would need to be a whole system that monitors the internet connection, the server connection and the network connection and figure out which failsafe cache to use if one of them goes down. It can be done but it would be very complicated and prone to errors.
QML was made for touch UI in mind. It also makes things like animation really easy.
Because GTK (doesn’t) handle touch UIs in a nice and natural way. They also make it difficult to use in any other environment outside of GNOME.
It would be difficult to write a USB driver when everything is running on a web browser. This includes situations where you are using WASM. There are also a number of issues about local storage when you use a web browser instead of a local application. There is also a chance that webUSB may never be standardized.
Yeah, but that would require Node.js and node-serialport. I really don’t want to deal with npm along with the security issues. Maybe I can isolate those libraries? Maybe I can put it in a VM? Technically the “front end” could be written in Node.js + HTML5, but that would be more difficult to manage than QML.
Yes, you can download and start using it now. However, you need to contact Tej Shah for the API keys for clearinghouse billing.
There are many ways to help depending on what you want to do. Please contact me at tshah.dental@gmail.com and let me know what you kind of things you like doing (backend work, git hacking, front-end design, artwork, etc.).
Please contact me at tshah.dental@gmail.com if you want to become a partner.