 So I apologize in advance if I'm going really fast, but I put a little bit too much content here. This is a quick outline of all the categories that I'm going to go over. So brief introduction on who I am. I graduated from Carnegie Mellon back in 2006 in information systems, human-computer interaction, and computer science. I worked as a software engineer for Lockheed Martin for a couple of years. I also worked for a company called ICS, where I got much more familiar with Qt and QML, and then I did the most logical next step for my career and went to dental school. So I graduated from Tufts in 2015, and I've been working as a actual practicing dentist for the last couple of years in different kind of environments, large corporations, small private practices, as a local tenant. Really I got a lot of diverse experience working in very different areas. So before I go over actual clear dental, let's talk about how other dental software looks like. So the big problem right now is this kind of chicken and the egg problem, where all the actual dental software is made for Windows, and so all the accompanying software is made for Windows as well. So it's really hard to get out of this loop. So that keeps not only Lennox, but other operating systems like Mac OS out of this loop. So there's a new PAN machine, great, but you can't hook it up to a Mac machine. You have to run Windows in a virtual environment just to be able to take that special kind of regraph x-ray. And the actual existing software for charting, for taking care of your patients, is very unintuitive, even for doctors. What does this button do? I don't know. You have to take a two-week long training just to understand what it's really doing. Is this just saying, okay, I want to try to plan something for the upper arch? Or is this trying to say, I'm making a denture? It's not really at all intuitive. There's a lot of buttons, there's a lot of options, and a lot of times you don't even know if you're doing the right thing. And just to even keep track of what you've done and what you need to do, all you see is just a line by line, a lot of mishmash of things that you don't really understand where you are overall. And then on top of that, it's more or less almost like an Excel spreadsheet. It doesn't really get you an idea of what you're trying to do for the patients. This is another, this is called EagleSoft. It's another popular one. It has some of the same ideas, which is, let's give the user a bunch of buttons. Let's use non-standard icons that nobody else would understand. And let's just do a line by line, nothing that any doctor can really understand. So how does that really work in a dental environment? Well, because it's not really that user-friendly, you tend to see doctors actually avoid using the computer as much as possible. So it's a dirty environment, it's a wet environment. You don't want to really get the computer in your way. So you literally have situations where you have the doctor training the patient. You have your assistance that is not doing the suction right now, but eventually she will be. And then you literally have somebody dedicated to writing all the case notes on a piece of paper and then typing it in again on the computer. This is from a colleague of mine. Now we're in a post-COVID environment where he wants to get everything nice and sterilized. She is right now wearing all the good PPE, lots of gloves, the patient's ice and protective with a vacuum. And of course, I thought it was kind of funny that, okay, what if she wanted to use the computer to look something up really quickly? Well, this kind of environment doesn't really lend itself to keyboard and mouse. Yes, you could get one of those kind of keyboards that can be sterilized, but they're really hard to type on. And you have to literally drop what you're doing in order to actually use the computer. So there are three major goals of Clear.Dental. One is to make everything as open source as possible. There is actually another project called OpenDental, which is itself open source. But it requires an proprietary operating system, a proprietary drivers, and proprietary image viewers. So it does a very small subset of what a doctor needs to do. The main idea of Clear.Dental is to make everything more open source. The second goal is to think more like a dentist. So you want to use the same terms that doctors actually use rather than what a computer scientist would like to use. And then have it such that it's touch friendly because you don't want to be really switching over to a keyboard and mouse each time you want to look up something. And the best solution that I found was actually using what's called a resistive display, which is different from capacitive, and I'll go more over the details pretty soon. So just go over the technology stack really quickly. My main target is, of course, Linux. I'm using Kombuntu for most of my testing. I'm abusing Git and PGP to make something that's very similar to a blockchain. It's not really a blockchain, but it has a lot of the same ideas as a blockchain. Deep speech. I'm trying to use as much existing open source projects as possible. So this is for if I want to do something that's voice activated. CryFS is mostly for encryption. So all the actual patient data is going to be stored using CryFS. I made a module called Clear.Dental backend, which has all the C++. And then I'm using QML and two quick controls to access whatever need from backend to create the interface. And each module has its own UI for whatever use case that you're doing. So just to give you an example of how it looks like, this is the pediatric exam. So you can see here that because I'm treating a kid, you don't see any options for, let's say, placing an implant because that would make zero sense. Why give the doctor options that are nonsensical? And why don't you just actually put something that would not only make sense, but you want to remind the doctor to do. Like, for example, okay, the kid presented with his mother, with his father, somebody else, what's the chief complaint. These are all missing in current dental EHRs. And then integrate the medical history. So I want to be able to check the vitals on each appointment, be able to do any kind of screens that I need to do before I start my procedure. Similar idea, I'm actually going to demo the extraction portion. So the idea is that you want to show what is relevant to whatever procedure that you're trying to do. And speaking of that, it's going a little slow right now. One second, sorry. Okay, so just to go over the actual user interface, the reason why I'm stressing so much on touch is because as I'm treating my patient, I always have something on my hands. On my right side is the explorer, and the left side is the mirror. And it's a real big pain to have to put them down on the tray, do something, get my instruments back up again, and then go back to the mouth. It would be really nice to actually use the same instruments that I'm using on the patient onto the touchscreen. Of course, I can wipe it down of the cabbage side between each patient, but it will be really nice and much more efficient to use the very same tools that I'm using to treat the patient to interact with the user interface. So here's the mirror and explorer again. When you're using a resistive touch display, it needs a certain amount of oomph to actually be able to register any kind of click. This will bend and probably break. Same thing with the periodontal probe. Mirror, you don't really want to tap using glass. So the best solution is actually using the blunt side of the mirror. So essentially use it as a stylus. Okay, now I am going to share my entire screen. Hopefully people can see it. Okay, all right. So I'm just going to go over this demo really quickly. So as a dentist, you're going patient to patient really, really fast. You don't want to make any mistakes, but sometimes mistakes do happen. There's sometimes small mistakes, sometimes it's big mistake, but any kind of mistake is not really all that acceptable. So here you're in a use case where you're about to do an extraction. And before you want to extract, well, you probably want to patient to consent. So you have the sign for consent. They can use their own finger or whatnot to do the consent. Okay, it's now signed. This is a new feature that I recently added in for COVID-19, because you should probably screen your patients before you actually treat them. Last thing you want is to have an outbreak because you treated a patient. For all patients, especially for something like an extraction, you want to take the vitals. So if you have a patient that has a blood pressure of 190 over 99, you probably shouldn't be treating that patient. And it's also good to see how much pain the patient is when they first come into your office for the day. And then, of course, if you want to review the medical history, there should be a really quick and easy way to do so. So you can say, okay, let's talk about your diabetes. Okay, A1C 6.5, that's fine with me. Are there any changes? I have a dedicated button just to say no changes because that's the most common result when you ask them, hey, has there been any changes to your medical history? They'll say no, because I'm using fake data here. This is all just random images, but this would be what's called a periapical radiograph. And then this would be the bitewing. So it only would show the radiographs that are relevant to the actual extraction that you're trying to do rather than show you a bunch of bitewings and PAs that are not relevant for this particular tooth. So it wouldn't show a PA of tooth number 14 because, hey, I'm working on tooth number three. For local anesthetics, the way that most dentists are actually doing it is they just, every time they use a carpule, they would put the empty carpule in a certain area on their dish. So at the very end of the procedure, they would just count up the number of carpules that they use. So it says, okay, there's two reds. There's one of the golden ones. So I must have used two lidocanes, one septicane. And if the assistant actually put them away before the doctor could write that down, then the doctor has to rely on their own memory, which is not always the best. So the best way to do it is actually use the computer to actually keep track of how many local anesthetics you've used. So in this case, I'll probably use one for, actually for number three, I would just use two septicanes and then just use one more cane. And then for the actual today's appointment, you can say, okay, did I section the tooth? Did I do any kind of socket preservation? And what kind of grafting material rather than trying to remember that? What kind of sutures? Did I create a flap? And then when you are completing the procedure, it would automatically generate your case note based on what you wrote down. So it'll actually remember, okay, I used two carpules. I used one carpule of marking. It will actually record that as you're doing that. You can even make a new prescription. Yeah, that was a pretty infected tooth. Let's do some amoxicillin, things like that. And then you can just either sign the case note or work on it a little bit later, because sometimes you want to write down something you want to write more about. Like for example, during the procedure, the patient really couldn't open their mouth. So you may want to put a quick note of trismus. This actually would be using the KDE virtual keyboard. I'm right now being lazy right now just using keyboard and mouse. But it's 100% touch friendly. You can write later on, write down. Yes, patient had severe trismus during today's procedure, but patient was able to tolerate just fine. Okay, let's see. Now let's stop sharing the screen. Okay, so just to go over the timeline, I'm not 100% done with everything with clear dental. There's still a few small bugs. I really want to drill down and make sure it is completely clean before I start using it on real patients, especially since I'm going to be doing things like taking x-rays on them. And last thing I want to do is zap them of radiation for no good reason. So I also am working on my own dental practice. So this is an actual private practice that normal people can come in and out. I'm right now still at construction phase. So I already bought a building. They're doing construction literally as we speak. And then it should be done by middle or beginning of December. And then hopefully by then, the software should be mostly bug free at this point. And then essentially I'll be doing two things. I will be running my practice as a normal dentist. And I'll be doing what's called Adir of Design. And what I mean by Adir of Design is my practice is going to be open Friday, Saturday, and Sunday, mostly because those are the times that my competition will be closed. So it's nice days to keep that open. Monday through Thursday is going to be the days that I will learn from all the mistakes, software mistakes, Friday, Saturday, and Sunday, use that to improve the software and then use it again on Friday. So it's this kind of like cyclic design that would use it to essentially make it perfect. Well, that's really the goal to make the right kind of dental software. I'm going to go out really quickly over some of the mistakes that I've made. Hopefully other people will avoid it. The first one is actually making videos of the Clear Out Dental doing demo videos. It turns out that when you talk to other doctors, it doesn't really make any sense. You need to actually show them with a real patient how it integrates with your office because you have to remember, most doctors keep the computer at the side, at the corner there, where it does its own thing. So they can't really see how computers can be integrated with the procedure itself, how it can really help them. Until you're actually starting to use your real patients, it wasn't actually that useful to show any kind of video. So the other mistake that I made was making my own new patient form that was customizable. The mistake here was thinking that doctors could make their own new patient form, customize it for their own practice. But then I took a Spear C course and realized the way how I was handling this was completely the wrong way. And me thinking, okay, I know QML. I know how to use Qt. Qt supports WebAssembly. Why don't I just write it in QML and I'll put it to WebAssembly? This was about a year and a half ago. Of course, I knew back then that mobile support was kind of poor and there were a lot of other issues with Safari and iOS. And I thought that it would be improving by then, but it's been a good year and a half now and nothing has really changed. So I had to rewrite it once again in Bootstrap. So I wrote an HTML slash Bootstrap with a little bit of JavaScript to do almost the same exact thing. It was very depressing to have to rewrite it all over again. Very, very long story short. If you are doing a sub-modules. So in Qt Creator, you have the option to do sub-modules. I'm signing off some of the sub-dears, I meant to say. Sub-dears in which you have different projects. That alone is fine, but then when you create each actual QML application, it will encourage you to call it main.qml, which can cause some issues in that whenever you are trying to debug something, Qt Creator will be like, okay, which main.qml are you talking about? And without spending too much time on this, I learned the hard way that I should probably not be using a C++ class for every specific .json file. I'll go a little more about that a little bit later. Another issue that I learned hard way is type coercion. So you can see this is a .json file. So here, tooth is an integer. Here, tooth is an integer. Here, tooth is a string. So you're thinking, okay, why do I have a string three? Well, that's because it could be a normal string and sometimes it could be numbered. It could be a letter. So permanent dentition actually means adult's tooth. Primary dentition is a baby tooth, which makes it really confusing because you actually hear pediatric dentists say, yes, it is tooth number C. Tooth number C, okay. But that's how they actually say things. But at the same time, I like to use. Oh, go ahead. Kind of out of time, so if you can wrap up so that we still have time for one or two questions, that would be awesome. Okay. So yeah, I learned a hard way that I should probably just disable the check for M126. Thinking that I should target asbury pie wasn't a good idea because it's a drop in a bucket. I did not put... Yeah, I have to go about this. That's a long explanation. But yeah, internationalization, all doctors speak English, trying to convert it to any other language would make more problems and solve anything. And I'll skip these suggestions and go straight to questions. Sorry, it took so long. This was super awesome. I think it was really awesome to see a completely new world. So yeah, there are some questions. I guess I'll read them for you. Thank you for joining Academy and giving us a new perspective. The first question is, have you heard of the GNU Health Project and would you consider bringing your project into their projects and working together? It's an HMS system that also has a veterinarian module. Lewis has a talk on that tomorrow. Yeah, I actually didn't know too much about that particular project. There are a couple of fundamental differences between my project and the GNU Health, in particular mine is trying to be more touch-oriented of QML. However, and also the way that the database is being stored is fairly different. Now, not to say that we can't have any kind of overlap, but it's something we can probably share some code. It won't be able to be merged. I don't think so honestly, but it's a good thing that we can probably say, okay, insurance for this kind of module, we need this kind of API and have some common code. But I don't see a complete merge of those two projects. Well, maybe you can have a chat during Academy. All right, we can take two more questions maybe. So if the reason for bad old software in the field is that vendors maintain direct relationship with doctors, how can this project connect to the audience and get more deployments? Yeah, so Henry Shine and Patterson have basically doctors more or less right at their right hand. I mean, I don't have a real, I guess, financial model on how to make money off of this and how to distribute basically outside of word of mouth, hoping that doctors would convert, but it's not that easy to make doctors care about open source. I mean, people already have trouble convincing people in IT to convert to open source. For doctors, it's 100 times more complicated and much more difficult to explain why should they care about having full control over their patient files. All right, last question. We'll take a Katie question there some more, but are you using any Katie frameworks, any of the libraries, and if other technical travels, why not, or are you? So I don't know if you want to consider Kirigami to be an actual Katie framework, but I was going to use that initially. But one of the problems I had was, there were a lot of different panels that I wanted to customize, and Kirigami was getting a little bit more in my way. One of the recommendations I had in my last slide was, okay, I think Katie should start promoting QML as more of a first class citizen. Still, everything is C++ Q widget-based, and it would be really nice if Katie E for Katie 6 to say, okay, the official way is to use this API. Everybody needs to start converting. That way we have one single way to do things. I mean, Kirigami doesn't even, I don't want to say they're like a side project, but it doesn't feel like it's the official way of doing things quite yet.