Replies

"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!

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).