OpenEMR scalability

innocuous wrote on Friday, December 02, 2005:

Hi,
We are testing OpenEMR to be installed for our HMO.
We will require a central installation on a high end server with T1 line which will be accessed by atleast 200 doctors to manage the health records and healthcare of atleast 1,000,000 families.
The central server will be running linux and hosting OpenEMR. The doctors will use laptops/desktops with linux or windows to access their logins and work over the internet or over a WAN.
Each doctor will have their own login id and will be able to access only his/her patient db.

Is this feasible with OpenEMR? What issues will we face and need to be resolved?

Can anyone please guide us to implementing OpenEMR for our HMO? We are against using propreitory systems.

Thanks

sankar1234 wrote on Friday, December 02, 2005:

If you use 200 Doctors using the commercial versions, you might have to sell India to these companies.

I don’t think anyone tested for 200 doctors, even the commercial version such as eCW, e-MD, Soapware…

andres_paglayan wrote on Friday, December 02, 2005:

Care about firewalling, open only 443, run everything under ssl.
use a good backup strategy.
Use it with the GACL option for better access control.
For the amount of clients connecting there is no problem.
if after couple of years the load is very high you can [relative easily] cluster it.

wpennington wrote on Saturday, December 03, 2005:

What is the scope of the test? 
What are your next steps if the tests are successful?
What are your next steps if the tests are unsuccessful?

Could you please post more information on your testing plan, and the goals for evaluation during the testing?

sankar1234 wrote on Tuesday, December 06, 2005:

You need to proceed with in-house system admin, architect who can direct the team of programmers both in terms of architecture of the system, design and development, QA team.

You need to have your CVS, bugzilla and a couple of systems for developers. I don’t think you can depend on the OpenEMR community to fix problems because of the turnaround time.  The team you acquire should be able to fix any problem that araises during the testing phase.  The following is a guidance, but it depends on the local conditions.

Consider Phase 1 with 5+ doctors: Publish the expectations of this phase 1 such as functionality tests.  Make sure you fix any problem. Functionality tests should have all passed in this phase.  Tag the CVS at this phase.

Consider Phase 2 with 15+ doctors:  Now you system should be very stable with actual hardware that is being used.  Check out how your system is performing.   Performance tests could be done using good QA engineers.  QA engineers should be able to stress the system at this stage.  The architect might have to fine tune the design both in terms of hardware and software. 

Consider Phase 3: Here you should have plans for making backups, scalability, fault-tolerant server tests, data-replication server policies and executed.

Release phase Ver 1:  If you are here and alive means, you system is ready to be shipped and ready for live action.

Final Signoff :