Hi,
We want to use OpenEMR for our health maintenance organisation which is a group of 200 doctors managing the health of appx 1,000,000 families.
We are very pleased with OpenEMR features and its ability of capture patient data.
However we find it lacking in two areas:
1) Drug drug interaction check
2) Clinical decision support sytem
1) A drug drug interaction check is vital to the concept of managed healthcare. Can OpenEMR be programmed to allow this feature? If yes, can someone guide us?
2) Again, to improve healthcare and to cut down or errors by the doctors, a clinical decision support system which checks tha patient stats, demograhics, medication and conditions, and checks them against the medication being prescribed will be highly useful.
If it finds any conflict, it should flash an alert on the GP's screen. The rules for checking the same can be coded into a database.
If these two features can be added, we feel OpenEMr will be among the best EHR out there.
Any help in getting these implemented will be highly appreciated.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The programming is easy. The problem is getting the database content, e.g. the interaction data and clinical expertise. Do you have a source for those, or a method for collecting the data?
-- Rod
www.sunsetsystems.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. The drug interaction is easy. The Medical letter (a non-profit organization) sells the database for $89.00. I was communicating with them, but they didn't respond. I will send the communication once again.
On the clinical support, It requires lot of time. One way is to change it so it is diagnosis driven or medication driven. In other words, when the physician selects a diagnosis code, the most frequently used H/P, Ex, PSFH, Rx should popup. In other words, the system will learn from previous encounters and diagnosis.
-Sankar
www.cvQuest.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Above are two companies that provide the drug interaction service and that keep the drug information current. These are examples of companies offering this service, and other companies provide a similar service. The companies above offer subscription services, and will likely cost $25-100USD annually per medical provider based on 200 providers.
Decision support for 200 users, and all of the specialties potentially covered by these providers, is a fairly sizable project. If you are planning OpenEMR with 1M families, you will probably want to engage in multiple tests of OpenEMR, the customization and create a plan for a proof of concept. A 3-9 month proof of concept using a subset of 10-20 providers and 50-100K families may be a good place to begin. I would expect that you will probably need a team of 3-6 people during the proof of concept for development, implementation, training, documentation and project management. Do you have a plan for a proof-of-concept? Do you have an RFP for this project or are your planning to hire supplemental internal resources? Who is going to provide third level support for the application and on-going maintenance?
For projects of this size, the company management and users generally need assurance that the application will be supported for three to six years following deployment, and assurance that once implemented that someone will be responsible for support, maintenance and training on the application. Management will be subjecting itself to serious financial risk in migrating to a new open source platform, and insuring that the investment today will still be usable, cost effective, and supported in five years is generally a weighty, and justified, management concern.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
-"Management will be subjecting itself to serious financial risk in migrating to a new open source platform,"
This sounds more like the final statement of a Microsoft funded comparison research. It is easy to mention 'risks', but there is no risk when you have the whole GPL-ed code written using one of the most popular programming languages. Read _any_ proprietary EULA, that's risky.
-"And insuring that the investment today will still be usable, cost effective, and supported in five years is generally a weighty, and justified, management concern."
My feeling here is that this is an effect of the “cover my back” culture. It is easier to say, pay $200k for that product and not taking any further responsibility. If there's a problem, is the vendor's problem, even if there is no solution, every decision maker remains guilt free. Serious management is about truly independence and best value too.
Any one who will be handling 200 MDs and 1M clients should have couple of ITs in house. If they are fairly good ITs everything should be well documented. And any other good IT should be able to take over by reading the documentation.
Scalability by clustering a Linux based environment is easy this days (as in out of the box cluster installation). In the other hand, how many of you are running critical data in 5 year old hard drives in your companies? You can't expect most hardware investments to last more than 5 years.
While data is the most important part, software is a little unpredictable, write anyything new modular enough so in the future it can be reused or ported to any new emerging language that could be the new de-facto development platform.
With decision support, I always ask my self: what are physicians for? There is still not enough proof that they do good more than bad. But an intelligent system that learns from the own database is tempting to have, as in evidence based.
I agree with most posts about drug interactions. Either way is fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think Walt was just saying "plan carefully", and probably did not mean to imply that an open source solution is any riskier than otherwise.
Perhaps what he doesn't know are: (a) currently the clinics are not automated at all, and so this is not really a "migration", and (b) it looks like the management wants to be very much hand-on and will not be turning over responsibility for success to a third party (however it seems they understandably want some advice and guidance from current OpenEMR developers).
It appears the management team is comfortable with open source and with OpenEMR already, and is prepared to devote adequate IT resources towards taking full advantage of the natural benefits of this kind of solution and ensuring its longevity.
This is exactly the kind of user acceptance and commitment to open source that we want to encourage and nurture.
Regarding scalability, I have been proposing use of a separate OpenEMR database for each clinic, combined with development of some additional tools for centralized management and reporting. I think this kind of approach will scale very well and will take advantage of the current strengths of OpenEMR.
-- Rod
www.sunsetsystems.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I second what Walt mentions. For tasks such as these, they have to approach this problem in a very professional and pragmatic fashion.
I would definitely consider performing experiments on OpenEMR and have resources to do enhancements to OPenEMR.
The things I would certainly look are : performace, scalability, distributed, replication, network, firewall issues.
For example, though EMR can handle many users on a sufficient memory and processor system, their local network architecture may hinder the performance considerably. A good system IT guy has to do good experiments before settling down with final installations.
Also, though Linux may be good for performance, but Windows servers will be system of choice because of lots of third party softwares are built for Windows.
Moreover, the local IT resources are more available in windows enviroment than Linux environment, and the costs of acquiring such resources are less. This should be the last consideration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sankar, the main problem is that OpenEMR does not go well with a windows install! I have tried hard to install it on Windows. Though I have got success, on some machines it runs out of the box, on others it gives errors even with same OS version! On MS server systems it always gives errors, and you never know when a new error might pop up if you upgrade or add another module.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For an organization already sold on the concept of an open source EMR, and one which is known to be happiest under Linux, I think trying to deploy it on a different, closed-source proprietary platform would be a very strange decision indeed.
By the way I'm getting the feeling that nobody noticed my suggestion above regarding a separate database for each clinic. This solves most of the scaling issues.
-- Rod
www.sunsetsystems.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"...Also, though Linux may be good for performance, but Windows servers will be system of choice because of lots of third party softwares are built for Windows. ... "
When talking serverwise, I can't think of anything missed out there for Linux.
Do you have an specific application that would be needed to run under a OpenEMR Linux server and which is not available under GPL?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the problem innocuous mentioned in prior posts is that these doctors are carrying laptops that run MS Windows already. Physicians are very resistant to change.
What you are proposing above is to convince 200 physicians to discard their current Windows OS in favor of what they will view as an untried and poorly supported OS. (It will be difficult to convince them that we are going to support them from inside the United States.)
They using laptops as the server for each physician. So far there is some variation from one machine to the next on whether the installed MS Windows version will even run OpenEMR.
OpenEMR seems to be fine on Windows XP and Windows 2003 server. The install on Windows 2000 can be dramatically more difficult.
The best solution may be to purchase individual licenses for VMWare. Install the VMWare on the laptops and then run OpenEMR on a Linux server inside of the VMWare environment. This has the penalty of cutting the effective RAM in half for both the "client" Windows browser and the VMWare\Linux Server.
Installing Linux on a variety of laptop hardware may not be a cake walk. Knoppix based versions would likely be the best at hardware detection. One could not know for sure until all of the laptop brand names and configurations were known or one had the time to do all of the installations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My understanding is that innocuous is more recently considering an ASP model, with the servers all at a central location. So the problems of installing on Windows laptops would go away.
However if not, there is now a free VMware Player which would do the job nicely. It's no longer necessary to purchase VMware for something like this. 256MB of physical memory is probably not enough, so yes, many of the laptops might need hardware upgrades.
-- Rod
www.sunsetsystems.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Earlier we were considering installing OpenEMR on individual laptops, each acting as client and server and later we add a synchronization module to upload data to central server
Thats where the issues of windows would come in.
Now what we think will be more practical is to have a central server hosting OpenEMR running linux. The GPs' can run whatever OS they prefer as they will only be clients connecting to the server
Same as your hotmail and other web accounts.
Yes, we do require that one clinic patients can be only viewed and accessed by the doctor in that clinic. No sharing of patients is allowed.
I guess the main area we will have to concentrate on is 1) hardware and backup 2)patient db 3)client access 4)additional modules ie formulary & decision support.
Btw I got OpenEMR working on a windows XP PRo install but on an XP Home install it again gave errors. I had to spend almost 2 weeks sorting the errors out, but again there is no reliability that things will always work whenever a new module or upgrade is added.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can also consider creating a http://www.colinux.org approach. To run a linux in a windows process. Works great for me. Need no special licenses,except GPL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't post my message to say Windows is the option to select, not Linux. I am also fan of Linux and I have worked in SGI and Disney with Unix platforms. My LSU 6 years are all in Unix world. I adore Unix world.
At Andreas question: Most Physician know only windows world. It is easy to sell a windows EMR for me, than Linux EMR though Linux is better.
To Innocuous answer: For a project of this magnitude, you could have hired programmers to fix this because you or your customers wanted Windows platforms. Otherwise you wouldn't have taken windows platform. Also, You have to understand that OPenEMR developer's test platform is Linux. So everything will work great under Linux, not windows. Because they didn't test it under windows. I spent almost 1 month to compile it in my windows platform. When I was done, next version popped up. Nothing worked again. I have to spend 1 more month again. So, the best option if I may suggest is: For a project of this size, you have to have to hire Php, mysql, html developers (on contract) on your site to fix these problems. Otherwise, the project may be very risky because your are betting your future without inhouse development efforts.
I have not followed their thread, so I am little on the dark side. I can't comment their future direction or plans.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sam, do you (or does anyone) have some thoughts as to what the user interfaces for these features should look like? Consider also the tools needed to accumulate content for a decision support database. If we flesh out these "wish list" items some more, perhaps someone would be willing to sponsor them.
-- Rod
www.sunsetsystems.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Drug Drug interaction should be an automatic feature every time a new drug is added to the medication list.
Names of the medications will need to be standardized (using a search function of the medication database) or at least the tool will need to ignore case for mataches. Also it will work best if the tool can recognize brandnames and associate them with generic names.
The easiest way to do this is list:
Toprol XL : metoprolol
Then search metoprolol for drug-drug interactions.
Drug Drug interaction lists tend to come based on generic names.
Adding a manuel button to initiate searches to check befor adding a drug to the list would be fairly easy.
Click a button in the problem list area labeled "drug-interaction"
A pop-up runs a dialog:
search the database for the name of the new drug
enter
business logic checks against the drug-drug database and issues a warning and how severe the interaction may be.
(A link to read about the interaction would be nice here.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just an international reflexion:
- Prescription modules tend to be very national; I am not fond of telling my patients to go to NY in order to fetch their medicine. They tend to like go to their nearest pharmacy...
Therefore a prescription module - of which an drug-drug interaction would be a part - should ideally be called in a new window. But we still like to have all prescriptionsdata loaded. So then it would be nice to have some kind of tracking or import-feature from the prescription-module that save the data in openEMR (in the same manner as KDEWallet or something?)
2. Decisionsupport. I have allready told you my view about this. If included it should be in a separate chooseable part. What is true in medicine at one clinic is not true in another clinic. Any global standard for treatment doesn't exist I'm afraid. Including decision support in a system where you still don't have other things perfectly working like referrals, inclusion model for certifications concerning sickness, healthyness, disease or accident is risky; focus is moved and we never get the important stuff to work...
Regards,
/Johan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Decision support will take more thought and effort.
I have approached this so far by designing forms that are driven by chief complaint.
I start with a chief complaint such as "bronchitis".
I then research a general way of taking care of "bronchitis". Currently I use "Saunder's Manual of Medical Practice". This book is very general and oriented towards family practice and urgent care.
I then create the form using the primary diagnostic clues as stated in "Saunder's Manual of Medical Practice", include the differential diagnoses, "clinical pearls" that help delineate different conditions, and a short list of diagnoses in a drop down box.
Then I go through the process of creating an OpenEMR "form". I think these might be more appropriately referred to as "clinical modules".
I would prefer to incorporate the search engines that you use in your "fee sheet". I could look up the diagnosis codes and fee codes from inside the "clinical modules". The billing function could then be initiated from inside of the encounter using the "clinical module" and the fee sheet search tools that you have already developed.
Your addition of the ability to associate a chronic diagnosis with a particular encounter is one of the first steps in this decision making process.
It does require standardization of the diagnoses being used. I think you should "require" the use of the fee sheet diagnosis search tool. None of this will work if the business logic can not make a match due to poor spelling or typos.
Say, as an example, I am seeing a 74 year old man with type II diabetes that is out of control.
I look up:
diabetes mellitus : 250.02 (poorly controlled type II DM)
I enter this as a chronic diagnosis.
I start an encounter using this diagnosis.
at the end of an encounter as I "finalize the visit". I get a pop up box that reminds me:
The following parameters needs to be checked:
*Hemoglobin A1c* (type II DM) quarterly
*Lipid panel* (Type II DM) anually and quarterly if abnormal
*Liver function* quarterly if on (search the med list for HmgCoA reductase inhibitors, thioglitazone (Avandia, Actos), etc.)
*renal function* (Type II DM) quarterly, warn if the last creatinine is/was 1.4 (men) or more and if 1.3 (women) or more. Critical warning if the medication list also shows any medication containing metformin.
*retinal exam* due every 6 months
*microalbumin to creatinine ratio* due annually or quarterly if elevated
*PSA* male over 50
One can see how ths will require some work. Ideally, a laboratory information system will become part of OpenEMR and these searches based on certain lab values will be checked by the "Decision support module" and reported only if data is missing.
In the "bronchitis module" "expert decision models" can be incorporated. These "Expert Decision Models" can arrive at the correct diagnosis with high degrees of certainty. This certainty level can be expressed as a probability.
This depends on setting up the forms correctly Signs and symptoms can "checked off" with explanatory text boxes.
The "Expert program would run off the presence or absence of the signs and symptoms (simple check boxes will do).
A "help" button to explain to the physician how the decision is being made and why. (Doctors don't respond well to being kept in the dark.)
This type of decision making is why I have been setting up the "clinical modules" the way I do.
Sam Bowen, MD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For what you are explaining here, it might be better to use a meta encouter form which picks the 'fields' to review according to the selected chief complaint.
Instead of forms, you can then set chief complaints and their relationship with the fields to be shown.
With a flexible way to add fields if not defined previously.
A centrally hosted repository, feed from all openemr installs (without pt id) can serve as the knowledge database.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We want to use OpenEMR for our health maintenance organisation which is a group of 200 doctors managing the health of appx 1,000,000 families.
We are very pleased with OpenEMR features and its ability of capture patient data.
However we find it lacking in two areas:
1) Drug drug interaction check
2) Clinical decision support sytem
1) A drug drug interaction check is vital to the concept of managed healthcare. Can OpenEMR be programmed to allow this feature? If yes, can someone guide us?
2) Again, to improve healthcare and to cut down or errors by the doctors, a clinical decision support system which checks tha patient stats, demograhics, medication and conditions, and checks them against the medication being prescribed will be highly useful.
If it finds any conflict, it should flash an alert on the GP's screen. The rules for checking the same can be coded into a database.
If these two features can be added, we feel OpenEMr will be among the best EHR out there.
Any help in getting these implemented will be highly appreciated.
Thanks
The programming is easy. The problem is getting the database content, e.g. the interaction data and clinical expertise. Do you have a source for those, or a method for collecting the data?
-- Rod
www.sunsetsystems.com
1. The drug interaction is easy. The Medical letter (a non-profit organization) sells the database for $89.00. I was communicating with them, but they didn't respond. I will send the communication once again.
http://medlet-best.securesites.com/html/software.htm is the URL.
On the clinical support, It requires lot of time. One way is to change it so it is diagnosis driven or medication driven. In other words, when the physician selects a diagnosis code, the most frequently used H/P, Ex, PSFH, Rx should popup. In other words, the system will learn from previous encounters and diagnosis.
-Sankar
www.cvQuest.com
ProxyMed
http://www.proxymed.com/eprescribe_formularies.asp
Epocrates
http://www2.epocrates.com/products/essentials/
Above are two companies that provide the drug interaction service and that keep the drug information current. These are examples of companies offering this service, and other companies provide a similar service. The companies above offer subscription services, and will likely cost $25-100USD annually per medical provider based on 200 providers.
Decision support for 200 users, and all of the specialties potentially covered by these providers, is a fairly sizable project. If you are planning OpenEMR with 1M families, you will probably want to engage in multiple tests of OpenEMR, the customization and create a plan for a proof of concept. A 3-9 month proof of concept using a subset of 10-20 providers and 50-100K families may be a good place to begin. I would expect that you will probably need a team of 3-6 people during the proof of concept for development, implementation, training, documentation and project management. Do you have a plan for a proof-of-concept? Do you have an RFP for this project or are your planning to hire supplemental internal resources? Who is going to provide third level support for the application and on-going maintenance?
For projects of this size, the company management and users generally need assurance that the application will be supported for three to six years following deployment, and assurance that once implemented that someone will be responsible for support, maintenance and training on the application. Management will be subjecting itself to serious financial risk in migrating to a new open source platform, and insuring that the investment today will still be usable, cost effective, and supported in five years is generally a weighty, and justified, management concern.
I strongly disagree.
-"Management will be subjecting itself to serious financial risk in migrating to a new open source platform,"
This sounds more like the final statement of a Microsoft funded comparison research. It is easy to mention 'risks', but there is no risk when you have the whole GPL-ed code written using one of the most popular programming languages. Read _any_ proprietary EULA, that's risky.
-"And insuring that the investment today will still be usable, cost effective, and supported in five years is generally a weighty, and justified, management concern."
My feeling here is that this is an effect of the “cover my back” culture. It is easier to say, pay $200k for that product and not taking any further responsibility. If there's a problem, is the vendor's problem, even if there is no solution, every decision maker remains guilt free. Serious management is about truly independence and best value too.
Any one who will be handling 200 MDs and 1M clients should have couple of ITs in house. If they are fairly good ITs everything should be well documented. And any other good IT should be able to take over by reading the documentation.
Scalability by clustering a Linux based environment is easy this days (as in out of the box cluster installation). In the other hand, how many of you are running critical data in 5 year old hard drives in your companies? You can't expect most hardware investments to last more than 5 years.
While data is the most important part, software is a little unpredictable, write anyything new modular enough so in the future it can be reused or ported to any new emerging language that could be the new de-facto development platform.
With decision support, I always ask my self: what are physicians for? There is still not enough proof that they do good more than bad. But an intelligent system that learns from the own database is tempting to have, as in evidence based.
I agree with most posts about drug interactions. Either way is fine.
I think Walt was just saying "plan carefully", and probably did not mean to imply that an open source solution is any riskier than otherwise.
Perhaps what he doesn't know are: (a) currently the clinics are not automated at all, and so this is not really a "migration", and (b) it looks like the management wants to be very much hand-on and will not be turning over responsibility for success to a third party (however it seems they understandably want some advice and guidance from current OpenEMR developers).
It appears the management team is comfortable with open source and with OpenEMR already, and is prepared to devote adequate IT resources towards taking full advantage of the natural benefits of this kind of solution and ensuring its longevity.
This is exactly the kind of user acceptance and commitment to open source that we want to encourage and nurture.
Regarding scalability, I have been proposing use of a separate OpenEMR database for each clinic, combined with development of some additional tools for centralized management and reporting. I think this kind of approach will scale very well and will take advantage of the current strengths of OpenEMR.
-- Rod
www.sunsetsystems.com
I second what Walt mentions. For tasks such as these, they have to approach this problem in a very professional and pragmatic fashion.
I would definitely consider performing experiments on OpenEMR and have resources to do enhancements to OPenEMR.
The things I would certainly look are : performace, scalability, distributed, replication, network, firewall issues.
For example, though EMR can handle many users on a sufficient memory and processor system, their local network architecture may hinder the performance considerably. A good system IT guy has to do good experiments before settling down with final installations.
Also, though Linux may be good for performance, but Windows servers will be system of choice because of lots of third party softwares are built for Windows.
Moreover, the local IT resources are more available in windows enviroment than Linux environment, and the costs of acquiring such resources are less. This should be the last consideration.
Sankar, the main problem is that OpenEMR does not go well with a windows install! I have tried hard to install it on Windows. Though I have got success, on some machines it runs out of the box, on others it gives errors even with same OS version! On MS server systems it always gives errors, and you never know when a new error might pop up if you upgrade or add another module.
For an organization already sold on the concept of an open source EMR, and one which is known to be happiest under Linux, I think trying to deploy it on a different, closed-source proprietary platform would be a very strange decision indeed.
By the way I'm getting the feeling that nobody noticed my suggestion above regarding a separate database for each clinic. This solves most of the scaling issues.
-- Rod
www.sunsetsystems.com
"...Also, though Linux may be good for performance, but Windows servers will be system of choice because of lots of third party softwares are built for Windows. ... "
When talking serverwise, I can't think of anything missed out there for Linux.
Do you have an specific application that would be needed to run under a OpenEMR Linux server and which is not available under GPL?
I think the problem innocuous mentioned in prior posts is that these doctors are carrying laptops that run MS Windows already. Physicians are very resistant to change.
What you are proposing above is to convince 200 physicians to discard their current Windows OS in favor of what they will view as an untried and poorly supported OS. (It will be difficult to convince them that we are going to support them from inside the United States.)
They using laptops as the server for each physician. So far there is some variation from one machine to the next on whether the installed MS Windows version will even run OpenEMR.
OpenEMR seems to be fine on Windows XP and Windows 2003 server. The install on Windows 2000 can be dramatically more difficult.
The best solution may be to purchase individual licenses for VMWare. Install the VMWare on the laptops and then run OpenEMR on a Linux server inside of the VMWare environment. This has the penalty of cutting the effective RAM in half for both the "client" Windows browser and the VMWare\Linux Server.
Installing Linux on a variety of laptop hardware may not be a cake walk. Knoppix based versions would likely be the best at hardware detection. One could not know for sure until all of the laptop brand names and configurations were known or one had the time to do all of the installations.
My understanding is that innocuous is more recently considering an ASP model, with the servers all at a central location. So the problems of installing on Windows laptops would go away.
However if not, there is now a free VMware Player which would do the job nicely. It's no longer necessary to purchase VMware for something like this. 256MB of physical memory is probably not enough, so yes, many of the laptops might need hardware upgrades.
-- Rod
www.sunsetsystems.com
Earlier we were considering installing OpenEMR on individual laptops, each acting as client and server and later we add a synchronization module to upload data to central server
Thats where the issues of windows would come in.
Now what we think will be more practical is to have a central server hosting OpenEMR running linux. The GPs' can run whatever OS they prefer as they will only be clients connecting to the server
Same as your hotmail and other web accounts.
Yes, we do require that one clinic patients can be only viewed and accessed by the doctor in that clinic. No sharing of patients is allowed.
I guess the main area we will have to concentrate on is 1) hardware and backup 2)patient db 3)client access 4)additional modules ie formulary & decision support.
Btw I got OpenEMR working on a windows XP PRo install but on an XP Home install it again gave errors. I had to spend almost 2 weeks sorting the errors out, but again there is no reliability that things will always work whenever a new module or upgrade is added.
You can also consider creating a http://www.colinux.org approach. To run a linux in a windows process. Works great for me. Need no special licenses,except GPL
I could spend some time trying to determine the minimum Windows OS configuration to install OpenEMR and have it run correctly.
I do have some recently reconfigured Windows 2000 Professional desktops in the office that I could try.
I didn't post my message to say Windows is the option to select, not Linux. I am also fan of Linux and I have worked in SGI and Disney with Unix platforms. My LSU 6 years are all in Unix world. I adore Unix world.
At Andreas question: Most Physician know only windows world. It is easy to sell a windows EMR for me, than Linux EMR though Linux is better.
To Innocuous answer: For a project of this magnitude, you could have hired programmers to fix this because you or your customers wanted Windows platforms. Otherwise you wouldn't have taken windows platform. Also, You have to understand that OPenEMR developer's test platform is Linux. So everything will work great under Linux, not windows. Because they didn't test it under windows. I spent almost 1 month to compile it in my windows platform. When I was done, next version popped up. Nothing worked again. I have to spend 1 more month again. So, the best option if I may suggest is: For a project of this size, you have to have to hire Php, mysql, html developers (on contract) on your site to fix these problems. Otherwise, the project may be very risky because your are betting your future without inhouse development efforts.
I have not followed their thread, so I am little on the dark side. I can't comment their future direction or plans.
Here are a couple of links that might help with VMWare stuff.
http://www.vmware.com/download/player/
Pre-built Browser Appliance Virtual Machine
Featuring: Mozilla Firefox 1.0.7 and Ubuntu Linux 5.04
http://download3.vmware.com/software/vmplayer/Browser-Appliance-1.0.0b2.zip
Download the Player and then use Pre-built VM. Ubuntu is already installed and ready to run just do OpenEMR install.
http://johnbokma.com/mexit/2005/11/07/vmware-player-ubuntu-installation.html
1) Drug drug interaction check
2) Clinical decision support system
These absolutely critical for any modern EMR / EHR.
Sam Bowen, MD
Sam, do you (or does anyone) have some thoughts as to what the user interfaces for these features should look like? Consider also the tools needed to accumulate content for a decision support database. If we flesh out these "wish list" items some more, perhaps someone would be willing to sponsor them.
-- Rod
www.sunsetsystems.com
Drug Drug interaction should be an automatic feature every time a new drug is added to the medication list.
Names of the medications will need to be standardized (using a search function of the medication database) or at least the tool will need to ignore case for mataches. Also it will work best if the tool can recognize brandnames and associate them with generic names.
The easiest way to do this is list:
Toprol XL : metoprolol
Then search metoprolol for drug-drug interactions.
Drug Drug interaction lists tend to come based on generic names.
Adding a manuel button to initiate searches to check befor adding a drug to the list would be fairly easy.
Click a button in the problem list area labeled "drug-interaction"
A pop-up runs a dialog:
search the database for the name of the new drug
enter
business logic checks against the drug-drug database and issues a warning and how severe the interaction may be.
(A link to read about the interaction would be nice here.)
Just an international reflexion:
- Prescription modules tend to be very national; I am not fond of telling my patients to go to NY in order to fetch their medicine. They tend to like go to their nearest pharmacy...
Therefore a prescription module - of which an drug-drug interaction would be a part - should ideally be called in a new window. But we still like to have all prescriptionsdata loaded. So then it would be nice to have some kind of tracking or import-feature from the prescription-module that save the data in openEMR (in the same manner as KDEWallet or something?)
2. Decisionsupport. I have allready told you my view about this. If included it should be in a separate chooseable part. What is true in medicine at one clinic is not true in another clinic. Any global standard for treatment doesn't exist I'm afraid. Including decision support in a system where you still don't have other things perfectly working like referrals, inclusion model for certifications concerning sickness, healthyness, disease or accident is risky; focus is moved and we never get the important stuff to work...
Regards,
/Johan
Decision support will take more thought and effort.
I have approached this so far by designing forms that are driven by chief complaint.
I start with a chief complaint such as "bronchitis".
I then research a general way of taking care of "bronchitis". Currently I use "Saunder's Manual of Medical Practice". This book is very general and oriented towards family practice and urgent care.
I then create the form using the primary diagnostic clues as stated in "Saunder's Manual of Medical Practice", include the differential diagnoses, "clinical pearls" that help delineate different conditions, and a short list of diagnoses in a drop down box.
Then I go through the process of creating an OpenEMR "form". I think these might be more appropriately referred to as "clinical modules".
I would prefer to incorporate the search engines that you use in your "fee sheet". I could look up the diagnosis codes and fee codes from inside the "clinical modules". The billing function could then be initiated from inside of the encounter using the "clinical module" and the fee sheet search tools that you have already developed.
Your addition of the ability to associate a chronic diagnosis with a particular encounter is one of the first steps in this decision making process.
It does require standardization of the diagnoses being used. I think you should "require" the use of the fee sheet diagnosis search tool. None of this will work if the business logic can not make a match due to poor spelling or typos.
Say, as an example, I am seeing a 74 year old man with type II diabetes that is out of control.
I look up:
diabetes mellitus : 250.02 (poorly controlled type II DM)
I enter this as a chronic diagnosis.
I start an encounter using this diagnosis.
at the end of an encounter as I "finalize the visit". I get a pop up box that reminds me:
The following parameters needs to be checked:
*Hemoglobin A1c* (type II DM) quarterly
*Lipid panel* (Type II DM) anually and quarterly if abnormal
*Liver function* quarterly if on (search the med list for HmgCoA reductase inhibitors, thioglitazone (Avandia, Actos), etc.)
*renal function* (Type II DM) quarterly, warn if the last creatinine is/was 1.4 (men) or more and if 1.3 (women) or more. Critical warning if the medication list also shows any medication containing metformin.
*retinal exam* due every 6 months
*microalbumin to creatinine ratio* due annually or quarterly if elevated
*PSA* male over 50
One can see how ths will require some work. Ideally, a laboratory information system will become part of OpenEMR and these searches based on certain lab values will be checked by the "Decision support module" and reported only if data is missing.
In the "bronchitis module" "expert decision models" can be incorporated. These "Expert Decision Models" can arrive at the correct diagnosis with high degrees of certainty. This certainty level can be expressed as a probability.
This depends on setting up the forms correctly Signs and symptoms can "checked off" with explanatory text boxes.
The "Expert program would run off the presence or absence of the signs and symptoms (simple check boxes will do).
A "help" button to explain to the physician how the decision is being made and why. (Doctors don't respond well to being kept in the dark.)
This type of decision making is why I have been setting up the "clinical modules" the way I do.
Sam Bowen, MD
For what you are explaining here, it might be better to use a meta encouter form which picks the 'fields' to review according to the selected chief complaint.
Instead of forms, you can then set chief complaints and their relationship with the fields to be shown.
With a flexible way to add fields if not defined previously.
A centrally hosted repository, feed from all openemr installs (without pt id) can serve as the knowledge database.
I would think that the generic names are more stable.
In my internet searches the generic names seem to be very stable though the brand names vary a lot.
This is one of the reasons making the comparisons among generic names becomes important.
As examples do you use:
simvastatin
lovastatin
pravastatin
metformin
metoprolol
carvedilol
?