Web Application Inside Desktop Application

Hi all,
I’m starting a new application that will store medical records.

I started out doing it for personal use, but am investigating a solution for small clinicians, as I’ve seen a few who really don’t have a good application for this stuff.

Anyway, the desktop application sits on a computer, a “secretarial” workstation of some sort.

I want to be able to create a Web Application INSIDE my project for the Desktop Application, notably so that they can share the SQLite database, and custom classes I’ve written.

I very much don’t want to have to do a cut and paste job every time I make a change in a function or class.

I’d really like to “insert” a Web Application INSIDE my project for the Desktop Application, so that they can share resources.

I know there are other options, such as a dedicated MySQL database server… but I want to do it this way.

I am pleased with the progress I’m making… The clinician application will sit on a secretarial workstation, and others will (hopefully be able to) connect through a web-based interface to access functions from the program, including but not limited to the records.

For now, this is just a project for fun… but I do see it going somewhere.

I would really appreciate an answer, as I am at the stage where I really want to get this done… I’m ready to start the web-based interface.

Thanks for everything.

You may want to consider building just a Web App that services all users and abandon the Desktop App. Doing so will cut your development time, provide your clients with a consistent user interface and means of launching it, and ease your support burden. As an added benefit, it will be easy to provide remote access to users off-site. They’ll get the same user interface they’re used to when in the office.

If you’re absolutely determined to create two Apps, one Desktop and one Web, or can’t do everything you want to with just a Web App then how you bundle/package them will depend on the target operating system platform and your preference because there are a variety of ways to approach it.

If you need the Desktop App then you may be better off focusing on moving to a more robust multi-user database instead of creating and managing both a Desktop App and Web App.

As a general rule, simple is good. The less complex, the better. Make everything as easy for your clients and for yourself as possible. Whichever of these approaches, or perhaps one that someone else recommends, is the simplest and meets all the needs of your clients and yourself is the one you should choose.

I appreciate the advice.

The web-based interface isn’t going to have all of the features of the desktop application.

The concept is to have a secretary / assistant use the desktop application on their end… They will have the ability to perform more tasks then the clinician who will use the web-based interface.

The web-based interface for the clinician will allow them to update their records, notes, etc… But as far as scheduling, adding and removing clients, amongst other features, will be only available to the secretary / assistant…

By having the desktop application on one machine, being able to perform many, many tasks, and then the clinician being able to connect to that computer via a web based interface (and thus removing the need for a central database server), being able to access records, make notes, add / remove information and changes, etc.

I’ve seen an in-house application before, and I want to create something similar, although with more features.

I am designing 3 versions:

Home / Personal - This version will store records for an individual.
Single Clinician - This version will store records and information for multiple individuals, being able to be accessed on a single computer
Small Clinician Office - This version will allow multiple clinicians to access information, as well as having one computer that is centralized for records, appointments, scheduling, etc… The application runs on an assistants computer, and then the clinician is able to login via a web-based control panel, to be able to make changes in their individual office. The system is still centralized, being designed for a small clinic… Individual clinicians are able to perform the same tasks via a web-based control panel, but it still relies on the secretary / assistant’s computer to keep records.

To put simply, I am making a more professional version of something I saw a small clinic do in File Maker Pro… The secretaries are able to run the full-version application on their computer, and then the individual clinicians can connect to the system and actually perform the tasks they would do.

Hummmm … I think the concept of a small office medical records system makes sense. But … Beware of HIPAA and other “legal stuff”.

I think (along with others) that there will be opportunities in moving back to health insurance that only covers catastrophic problems.

Who is getting rich off of ObamaCare

I have done some medical stuff and have a small pharmacy system written in a different tool (PowerBASIC). I have one client/pharmacist that makes a decent living only filling cash prescriptions. He thinks with the Affordable Care Act that there will be more cash prescription sales as people sign up for the low end Bronze plans and don’t have very good co-pays on brand name scripts. He helps his patients by contacting doctors and assisting in converting them to a similar generic he can sell for cash when they cannot afford the co-pay of the high priced brand name. His profit margin on brand names is very low and sometimes he loses money. A generic can save the patient money AND the pharmacist has a higher margin. Seems strange but true.

The pharmacist I know is moving forward into a concept of opening a pharmacy in a small medical center NOT in the affluent side of town that will have “connected” doctors. A small medical records system for the docs will be needed for these types of arrangements.

You can email me directly at Mark@SimplyBASICsoftware.com if you want to explore further.

Hi Mark,

I will email you later to explore this further, once I have made more progress.

I can most defiantly see the advantage of this sort of application for that purpose… In the sense that the pharmacist can have the desktop application on his end, and the doctors can connect via a web-based panel…

I wasn’t intending on this operating across the internet, more so an intranet / LAN… Although if I were to have it run in that sense, I would really look into using a VPN solution, such as OpenVPN, to ensure that the traffic is encrypted completely, or have it go over SSL/TLS.

As I said, I am working on 3 versions… I am working on the single clinician version now… I will later customize it and have a single user (personal use version)… Once that is done, I will add on functionality for a web-based interface for use in a small clinicians office, being as I had said - A secretary or assistant’s computer runs the full-blown application, which has a bit more functionality (scheduling, report generating, etc), and then the clinician can connect from their workstation to the full version via a web interface… having access to things that they will need to be able to do, more so notes, clinician logs, etc.

Hi Mitchell, your design sounds very good, and you can make it work by doing some tweaks in the router. Set the computer IP as static, use a different port other than port 80, you can use 8080, which is the default, then in the router forward that port to that computer. Doing this you will have a web server which can be accessed from outside by typing http:\\public_IP:8080. This is not secure enough to handle that kind of information. But, keep in mind, that in the event you want to add another user, that person will have to use a web application to access the data, since SQLite is a standalone DB, so the best approach is start your application scalable from the beginning by using a multi-user DB, such as SQL Express, which is free and will be able to handle that amount of information for couple of years.

I agree with Frederick, I think your best choice would be create a web application, that will make your life easier at the moment of deploying an update, you won’t have to go there or connect remotely to deploy the changes in each PC.

Good Luck !!!

Don’t ever do that. Have two projects, one desktop and one web. Common classes and modules should be external items in each project. That way the projects can share the same exact code.

Keep in mind that SQLite is not a true multiple user database engine. You can usually get away with supporting small groups using SQLite. But if the application will need to scale, you will want to use PostgreSQL or MySQL, my recommendation being PostgreSQL.