Replies

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