Web Application Development Question(Vanity)

I am assisting in developing a web application (i.e. I am hiring somebody to write the app). It is replacing a current application that uses Notetab Lite. Notetab using scripts allows a user to search for .tiff and .doc files that have been scanned into certain folders. The user double clicks on the .tiff file and a tiff viewer (Black Ice) comes up with the image (scanned black and white forms duplex). The "Server" is usually a Windows XP Pro workstation that is used by a daily user. The usually are 256-512MB RAM, 40-80GB Hard Drive and a P4-2.8GHZ. The daily user uses Notetab and Microsoft Remote Desktop. The "Server" is backed up remotely via Microsoft Fileshare (synch) to a remote Server.

The Doctor that created this wants to market and sell it as a cheapo EMR application. Currently the only doctor offices that use it are the ones that belong to his group (4 or 5) and maybe a couple of others. He agreed that the current state of the app is primitive and amateurish. SO he was looking to add a web interface to it. He was under the impression that he could just strap on a free website template.

I had one developer take a look at it to see if he could put PHP on the front end and have PHP interface with Notetab. The Doctor was very adamant that Notetab be kept as part of the new app. The developer said that there was no way he could get the PHP scripting to work with the Notetab scripting and beside it would be easier to just do it in PHP alone. I showed this to the Doctor and he was still adamant about keeping Notetab. Talks broke off and after a few months go by, I decide to go a head and create the app that I wanted. I am looking to do this in PHP/Apache/MySQL. It was suggest to me to use PERL for scripting the files form the scan folders to MySQL database. I think instead I will have the files scanned in and then be uploaded via the web app into the database.

Now for the questions. I am mostly a hardware techie supporting networks, workstations, servers and such so application/programming is out of my area.

1. Does PHP/MySQL sound like a good fit to replace this Notetab?

2. Can I run multiple databases (Live, Test and Training) per website (http://application:9090) or do I have to have a separate website for each database (http://applicationprod:9090, http://applicationqa:9090)?

3. Based on a one Doctor doctor office(5-20 users) will a beefy workstation class PC work for the "server" or should I be putting this on an actually Server?

4. Back to the multiple database question. If I have a server farm at a co location and charge an access fee to the doctor office. Can I have one web app running on the server and when the user from Doctor A logs in he/she can only see Doctor A database or would they have to log into a separate site, http://doctora:9090?

#1 - I've never heard of Notetab, but apparently it is some sort of text editor. If the text is simple enough to enter into a web form, PHP could be used.

#2. - MySQL supports multiple databases, which are specified in the SQL language. You could use distinct domain names, but that would make more sense if the databases were hosted on different servers.

#3 - I'd go with a server. If PHP is used, I'd use Linux for the operating system with Samba for file sharing with Windows clients - with per-user access privileges.

#4 - If I recall correctly, MySQL can authorize different user accounts for access at various levels - database, table, field, etc. It should not be necessary to run multiple MySQL processes to prevent unauthorized access to data.

Here is some unsolicited advice -

Rule #1 - Don't get involved with doctors who want to be computer programmers. It's always a disaster.

Rule #2 - Don't store large TIFF files in a database. Use the shared file system instead, and store a file path to the image in the database.

This web site and I disclaim any liability for the comments above. Use at your own risk.

I thought Notetab was some sort of a freeware version of some text editor? If it has some scripting capabilities, it sounds like some sort of round about way of doing things, probably, it was a 'temporary' solution of some sort.

If I understand correctly, you just want for the users to be able to view image files stored on the server in folders and open them on the client end with some sort of an app. The files are stored somewhere in the filesystem on the server. You are running XP. If all you need to do is to securely store the files, retrieve them (using a web server) on the server side, and view them using whatever viewer on the client side, I don't see the need for mysql. The filesystem security will take care of access to the files, i.e. a doctor will only be able to view his own stuff; if you are going to use Apache, there are quite a fiew security features provided with it. All you'd need would be a PHP, Perl or whatever based small app to provide some sort of web interface.

#1 - I've never heard of Notetab, but apparently it is some sort of text editor. If the text is simple enough to enter into a web form, PHP could be used.

It caused a lot of confusion for me as well, especially since it was a text editor. I think the Doctor used it since it was free.

#3 - I'd go with a server. If PHP is used, I'd use Linux for the operating system with Samba for file sharing with Windows clients - with per-user access privileges.

I had planned on Linux. In fact I was going to play around with rPath LAMP this weekend. So you suggest that the user scan the images to a mapped Images folder on the Server? How than do you store a file path in the database?

Here is some unsolicited advice -

Rule #1 - Don't get involved with doctors who want to be computer programmers. It's always a disaster.

Oh I know, I was going to push that he would have to relinquish admin controls. That is a reason why I want to to it my way so that I only cut him in for his assistance in marketing and selling the app.

Rule #2 - Don't store large TIFF files in a database. Use the shared file system instead, and store a file path to the image in the database.

See above. I guess this is why Misys EMR the user scans the document in with the Misys Document Manager Utility. This adds the information from the paper to the patient record. Then an image is saved in the Images folder. Than the workstations and application server have a mapped drive to the Images folder.

This web site and I disclaim any liability for the comments above. Use at your own risk.

No problem. Like I said I will be hiring somebody to do the programming. I am just trying to learn as much as possible before our next meeting.

"If all you need to do is to securely store the files, retrieve them (using a web server) on the server side, and view them using whatever viewer on the client side, I don't see the need for mysql."

I was planning on the website being the viewer. Is this not possible? What other way should I view and what at that point would be the use of PHP/PERL or I am reading you wrong?

I wanted to make the app web based so that no software would be necessary to be installed on the client side. Am I going about this wrong? I know there will need to be a workstation with a scanner attached (Scanstation). The other issue is that the patient information would need to be added in plus a patient record assigned to the patient. Currently the user searches on the patient's name. Which is OK up to the point that you get two or more Rob A. Johnsons.

I guess what I envision the user logs into the website and types in the keyword to search for the patient and the another field underneath will show the search results. The user than clicks on the right patient which will bring up a list of images/documents in a form of a link. The user then clicks on the link and the image/document is brought up with in the web app to view.

From the minimal description provided, with the requirement for some basic search capabilities, I'll speculate that it would be best to design your application to run on a server with a database and server-side scripting. I'd probably use an Apache web server with PHP and MySQL. With the appropriate hardware, it should scale up to handle the number of users you envision. If the lifecycle of your software is several years and you're going to use contract developers, I'd recommend PHP over Perl for better maintenance over time.

Here is a book I recommend: MySQL Cookbook by Paul DuBois. This can give you some good ideas and save a lot of R&D time.

I assume that your scanned images are electronic replicas of paper forms, not scanned x-ray films or something where advanced image processing and high-fidelity are required. In that case, a web browser should be adequate for viewing the images. Keep in mind that TIFF images are larger that most image file formats used on the Internet, so you'll need adequate bandwidth. I've seen networks get bogged down on TIFF images. Image compression could help - if your browser can handle it.

For this type of application, it may be advisible to use a secure protocol on your web server, like "https". That will encrypt the data sent between the web server and browser.

You may need to become familiar HIPAA privacy regulations, and be mindful of those while designing your product.

It sounds like an interesting project, and I hope it will be financially rewarding for you. Good luck!

Want file type for images do you recommend over .tiff?

Yes I know HIPPA pretty decently. That is one of the problems with the current application. No log in and the file names and searches are done by the patient name. I would prefer to switch that to an anonymous record number.

The files being scanned in are 8.5x11 sheets that have printed forms on both sides that a doctor feels out and writes notes on. At the moment there is no standard on that. Also anything sheet of paper that a note may have been written on might be scanned in. It would be nice to be able to add notes via a tablet or workstation. But that can come later on.

Yes I thought about doing https:. The server will be behind a firewall and even if I colo the server than it will still be behind a firewall and a VPN connection would be necessary.

"...
2. Can I run multiple databases (Live, Test and Training) per website (http://application:9090) or do I have to have a separate website for each database (http://applicationprod:9090, http://applicationqa:9090)?
..."

You should be able to use one webserver to reach all ie. HTTP://www.application:xxxx/QA, HTTP://www.application:xxxx/PROD, etc. But running the other servers may provide further protection from accidentally putting test data into your production environment and vise versa. I assume you have user accounts setup for testing, training and production and these accounts do not span across multiple systems. I just thought I would comment on your post, as I'm currently developing a system for a small business. Hope my thoughts were useful to you in some way.

CT

Well, you could use a server as a viewer but that would complicate things unnecessarily, it's better to leave it to a web browser to display the image, tiff format may not be widely supported by the browsers, so, if the images are documents where some quality loss is acceptable, some other format may be better - like jpeg (disk usage gain as well), for instance. If the image quality is critical (if you need to ensure no loss at all), then you may have to use tiff - then the clients will have to have some sort of a viewer installed (if your clients are using XP boxes, it's there by default, no action needed).

If you'd like to provide an application to access the patient's details, you can definitely do it with PHP/MySql/Apache backend; the platform can be either Windows or Linux, that depends on what skills are available for maintenance and license costs. If the doctors have to be treated as separate customers, some transparent way of data segregation need to be considered, i.e. not only built-in MySQL's security features but also some form of data partitioning, but that's down to the requirement and the application designers.

On the capacity side, it all depends on SQL and Apache traffic, if there are lots of queries from, say 50 concurrent users, I'd go for some form of a dual CPU server, with some not too new AMD opterons - 2 GHz would do fine, the system like this could be build relatively cheaply as those CPUs would not be expensive and the board would be realively cheap. At the same time you'll have considerable space to grow without having to upgrade the hardware.

I'd also steer away from storing images in the database tables, rather use some form of a link to the file's location on the filesystem (you could even give them a choice of viewing high quality image or a normal quality based on what type of an image they require).

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.