Suitability of OpenEMR as a national system?

OpenEMR Development
1

openemrhq wrote on Tuesday, April 21, 2009:

Hello Everyone,

We’re currently working on a proposal to deploy a nationalized medical records system throughout a mid-sized African country.  While we’re evaluating several different technologies such as VistA and OpenMRS, we are, at heart, an OpenEMR company and would like to see OpenEMR move into this role.

The situation would be that each clinic would have their own installation of OpenEMR but would use a common nationalized DB to access patient data. Network access would be via a combination of Mesh and WiMAX networking technologies.

There would also be a few hospitals on this network.

My question is: do you believe OpenEMR is capable of supporting this type of deployment?  What special considerations do you believe need to be made when doing something on this scale?

Thanks!
Dave Kennerson
OpenEMR HQ, Inc.

2

ideaman911 wrote on Friday, April 24, 2009:

Dave;

Our usage suggests that the problems will start when each clinic has their own "install" but the patient data resides in a single database.

Not being a programmer, as such, but looking at the data structures, there are a lot of intertwined log things which keep track of counts etc and ID’s.  So instead of using actual data, we use representative values (the ID) for a host of cascading data.  Break any one of them and the rest will rapidly go out of sync.  So if individual facilities assign ID’s, there will inevitably be conflicts.

Conceptually it seems possible for all the facility and user and what-not to be location specific, and ONLY access the central database for patient-specific info.

But the current discussion about multi-facility from single OpenEMR would seem to be a micro-description of the problem you describe.  As currently made, OpenEMR must allow all users to be defined to the one system, and therefore available to any of the facilities.  Putting a facility "preference", so long as that could be overridden as needed, would allow a limit on the size of the lists displayed, but not really reduce the size of the search except by that facility index.  And as soon as a patient or provider came from another facility, finding their record could be tedious unless they had some ID which helped to speed the search, like a barcode of the "favorite" facility.

There may be an added wrinkle - I heard that Oracle has bid to purchase Sun.  Not sure if that would potentially help or hurt the future of MySQL as used in OpenEMR.

Just some thoughts.  That sure would be a kick to see it :wink:

Joe Holzer    Idea Man
http://www.holzerent.com

3

openemrhq wrote on Friday, April 24, 2009:

Hi Joe,

Definitely some good points to ponder, but I’m curious as to your take on our proposed setup and how it might effect the issues you raised:

Basically, we’re talking a centralized database for all patient data from across the country. Everyone will have their own OpenEMR installation, but all installations will pull data from the master, centralized database as well as download a copy of the db (incrementally) every night.

The idea is that no matter where a patient might seek medical services in the country, their medical history and records will be available to any practicioner they might see.  This would necessitate a centralized db. Since the country does not have a HIPAA concept or a major concern for medical privacy, cross pollination and data being accessible to multiple providers easily isn’t a concern.

Does this have any impact on your statements above? Can you still see data integrity problems?

Thanks!
Dave Kennerson
OpenEMR HQ, Inc.

4

bradymiller wrote on Friday, April 24, 2009:

hey,

I’d probably just do a mock up several single openemr installs along with a mock up of your centralized mysql server and see what happens.  The perfect testing scenario for the openemr virtual appliance.  Vmware website has some nice free mysql appliances.

-brady

5

aperezcrespo wrote on Friday, April 24, 2009:

Hi
  This sounds like database replication.  Take a look at this and see if it might be of use.
http://dev.mysql.com/doc/refman/5.0/en/replication.html

Thanks

6

ideaman911 wrote on Friday, April 24, 2009:

David;

MY reason for getting involved with OpenEMR in the first place has a parallel here.  My NP wife (Lynne) has a rural house-call practice for which she wanted an EMR system.  Because G3 is as reliable in rural America as in Africa (ie NOT :wink: it was essential that her system be capable of stand-alone.  Knocks out 95% of the EMR alternatives.

BUT, she also has a third party (to say nothing of her fourth party, yours truly :wink: who has to interface with her data for billing.  Knowing that 80% of the time spent by the biller need not have any access to Lynne’s realtime data, so long as SOME recent copy thereof would be available, meant PRECISELY the system description you suggest, only on a smaller scale.

I elected to use Lynne’s tablet notebook computer, with automatic handwriting and voice conversion, as the “Master”.  Each night, while she sleeps, it automatically backs up to a server, so the Biller (Ruby) can look for the most part to that server for info, and need only interface with Lynne’s computer on a periodic basis.  We use Windows XP, merely because of MY limitations :wink:

I found a neat VPN called Hamachi, by LogMeIn.com which is pretty cheap ($5/mo/machine max) but which can be setup once, then find each other on our exclusive “network” anytime one of us is on the internet or our local LAN via any portal, including firewalled, ANYWHERE.  That way, if Lynne happens to stop at a hotspot, Ruby will know it almost immediately without any action by Lynne (our Thinkpad X61T’s are set to connect automatically if WiFi is available :wink: and so can do her actual billing schtick while Lynne has lunch or a potty break.  And it includes a “chat” and FTP function which works fine, so the stationary “office” can upload her scanned documents, etc., whenever she is at a hotspot.

I think that looks EXACTLY like your "nightime" distribution.  Where there is a problem I see will be in somehow "accumulating" the local, then posting to a central location each night.  That can best be explained by considering when a patient visits clinic A in the morning, then has to visit clinic B later that day for some reason.  When the night activity occurs, which will be taken as precedent data?  Is the clock able to be used?  Not as currently configured, as OpenEMR really deals with each transaction as it arrives as discrete, so makes the next effectively sub to that.  In any case there will be the current problem when two providers are seen on the same day - only the first to bill will be paid by insurers, but that is not the fault of OpenEMR, nor readily addressed therein, except to bill immediately ;-).

Those issues are what made me shy away from hoping to "sync" as you suggest.  But that was certainly my intended at first.

Your "fixed site" approach is more like the 95% ROW EMR packages which depend on continuous online.  I simply think that Africa especially is unlikely to be satisfied with that model.

I’ll be happy to consult about our process if you wish.  Contact me via link below if so.  Thanks.

Joe Holzer    Idea Man
http://www.holzerent.com