bradymiller wrote on Tuesday, November 22, 2011:
Hi,
Wondering if there are any pros/vendors whom are able to provide basic installation/customization support (for a fee, of course) for all of the platforms (windows, linux, virtual appliance, and even maybe mac)? Just trying to provide a couple users with some recommendations.
thanks,
-brady
sunsetsystems wrote on Tuesday, November 22, 2011:
Generally I do that kind of support for my clients who also want development work done, with the primary focus being on the development. I avoid clients who are not willing to donate the work to the project.
Incidentally I advise against a Windows server as Linux is easier to support remotely and is more consistent with the open source approach. If they gotta have Windows then I’ll install Cygwin. Macs are also possible, subject to discussion.
bradymiller wrote on Tuesday, November 22, 2011:
Hi Rod,
I generally deal with a couple emails a week for helping users set up OpenEMR and have noted since the 4.1.0 release there have been more requests for professional help. For linux users, it is easy to provide some recommendations, but for windows users, not as straightforward. For the cygwin windows approach, are you able to install/configure cygwin/openemr remotely for the users also (via one of the many remote windows assistance programs)?
I completely understand your philosophy on why linux is better than windows in so many ways for OpenEMR, but practically speaking, the vast majority of new downloads/installs are for windows. I think a good approach here is to discuss the options obviously, and then for ease of use during the trial period could initially use the cygwin/openemr approach and then when they are comfortable with OpenEMR could consider migrating (which is very easy to do) to a linux system/appliance/cloud. These are just some thoughts.
-brady
zhhealthcare wrote on Tuesday, November 22, 2011:
Brady
We specialize in windows as you are well aware.
We would be able to support those kinds of installations.
Shameem
yehster wrote on Tuesday, November 22, 2011:
Brady,
All of my development and test machines run Windows, so I run OpenEMR in virtualized ubuntu instances under VMware.
As far as I can tell the only advantage of running under windows is to eliminate “fear of linux.” Beyond philosophical reasons, there are also technical reasons, such as bugs, even critical ones like the encounter ID/audit log issues with XAMP newer than 1.7.3.
My approach to supporting a windows or a mac customer would be to teach them about virtualization and teach them basic linux. It might take slightly longer to get such a customer up and running that way, but it would be worth it in my opinion down the road. The only 'significant ease of use" from XAMP is for the install itself, and that is what the customer would be paying one of us so called “professionals” for.
Plus, virtualized servers provide an additional backup strategy (copy the whole machine), and gives a good option when it comes time to test/migrate/upgrade.
-Kevin Yeh
kevin.y@integralemr.com
sunsetsystems wrote on Tuesday, November 22, 2011:
Hi Brady,
Yes Cygwin can be installed and set up remotely via something like Remote Desktop or TeamViewer. Basically it serves as a collection of tools to facilitate support, and can also be very useful as a foundation for automated differential backups using rsync. Pretty neat really.
Virtualization certainly has its place, especially for teaching and testing as Kevin indicates. However it adds another layer of complexity and overhead so is not a cure-all.
yehster wrote on Tuesday, November 22, 2011:
Rod,
After the initial configuration through remote desktop or team viewer, do you continue to use those mechanisms to connect to the customer machine? Or do you use openSSH under cygwin at that point?
Virtualization is not a cure-all because no such thing as a cure-all exists! Each solution option has its advantages and disadvantage, and everyone has their own preferences.
Given the computing power available these days, I would argue that the overhead required for virtualization is negligible.
-Kevin Yeh
kevin.y@integralemr.com
sunsetsystems wrote on Tuesday, November 22, 2011:
Hi Kevin, I would use openssh after Cygwin is set up and the local router is configured appropriately.
tmccormi wrote on Tuesday, November 22, 2011:
Medical Information Integration, LLC supports all OS platforms for installation and support of OpenEMR, hosted or locally installed.
1/2 of my development staff uses MAC OSx as their primary development/OpenEMR environment, the rest prefer Linux variants. We all have depth in Windows servers are well. We run many VMs for various needs, from production to testing as well.
Tony
bradymiller wrote on Saturday, November 26, 2011:
Hi,
Thanks for the replies and good to know you can all support Windows(and even MAC) installs.
Tony brought up another issue in another thread that I’ve been wondering about: “Code that can be contributed back into the project typicallyt takes longer than code that is usable but not “up to standard”.” (quoted from Tony in another thread) And this also ties into an article on the wiki I was gonna do at some point:
http://www.open-emr.org/wiki/index.php/Open_source_openemr#Discuss_how_to_choose_vendor.2Fsupport
The question is how much more does it cost a user (an average percentage) to have the feature developed “up to standard” vs. code that isn’t. This is something that I’m guessing is vendor dependent; for example, vendors that can get code into the main codebase on the first/second review cycle vs fifth/sixth review cycle. Does it make sense to make this information public (ie. showing a vendors track record of successful feature commits), so users then seek out these vendors(thus ensuring code contributed by users gets into the official codebase with the least amount of cost to them)? Just wondering; even if wanted something like this, not sure how it could be accomplished with our limited resources.
-brady
sunsetsystems wrote on Saturday, November 26, 2011:
I don’t offer an option of substandard code to my clients. Usually the agreement is that it will get into the code base if that is appropriate. I strongly encourage other vendors to do the same, and encourage those who hire them to insist on it.
I’m reluctant to see the project getting into the domain of recommending vendors, and that could easily be seen as a conflict of interest. Also it’s healthy for the project to encourage new vendors to get involved. I suspect it’s better to just tell people how to look at forum activity and commit history (this is already public information) to see who’s being active and productive, and otherwise let vendors blow their own horns.
mdsupport wrote on Saturday, November 26, 2011:
This relates to Brady’s question about incremental costs to user for developing “up to standard” code.
In some cases there are significant costs related to “up to standard” code due to the nature of the current code base. A simple case would be that of the standard (correctly) requiring the new code to function across major browsers. In some cases that can amount to significant time and effort in testing alone. If the customer has a single browser for OpenEMR, those costs have little short-term benefits. We explain the long term benefits in terms of reduced maintenance costs but typically also absorb post-delivery costs to get it in standard code base as just the part of doing business in open-source world.
A separate and more significant issue relates to the costs of modifying the standard workflows. You see it currently affecting the code base is through use of IPPF and other custom modifications in “standard” release. So for major process changes it is easier/cheaper to do inline code changes making it harder to contribute. If the standard code were to allow for localization (e.g. use of include vs require in php) at specific logical decision points, it would make easier to contribute and give installations a far greater choice to ‘add-on’ functionality.
bradymiller wrote on Saturday, November 26, 2011:
Hi,
Agree with avoiding straightforward public recommendations by the project. The choosing of a vendor is an additional complexity to using an open source EMR and deemed by some to be a negative factor, when in fact, it is actually one of the huge benefits to going open source. Providing instructions for users on how to find a vendor will be useful (see wiki link in my post above), and agree looking through the forums and commits is very helpful, however basic users will be unable to look through the commit history very effectively (additionally, some vendors have multiple developers, so is not apparent that it is from a given vendor).
I agree with the “let vendors blow their own horns” philosophy and wanted to get thought on the following proposal:
On the http://www.open-emr.org/wiki/index.php/OpenEMR_Commercial_Help page, each vendor has the option of making a link to their own standardized “Features Developed” (or some title like that) wiki page that only lists what features they have successfully contributed to the official codebase. This nicely provides not only the quantity of contribution, but, more importantly the subject areas of contributions. And it takes away no resources from the main project (except for the occasionally checking of pages to ensure they are only listing these features. Thoughts?
-brady
bradymiller wrote on Saturday, November 26, 2011:
Hi mdsupport,
Can you provide a quick example of what you mean by include vs require; there is no reason for us to not allow more ‘add-on’ functionality.
-brady
bradymiller wrote on Saturday, November 26, 2011:
To clarify above: we should allow ‘add-on’ functionality.
tmccormi wrote on Saturday, November 26, 2011:
I find that it takes about 1/4 to 1/3 more time to get from code that works well for a specific customer to code that can be contributed to the project and works well for a broad range of customers. This is partly due to the code complexity as mdsupport mentions and partly because a broader audience usually means adding configurability, options, language support and security that the customer could care less about and is not (usually) interested in paying for. We tend to do it anyway on our own nickel. But not all developers or businesses can afford the extra effort.
As I have mentioned, many times, I think embedding custom work flows in the code using a pile of if/else statements is a bad model. That has not changed, so I won’t dwell on that issue here.
Tony
www.mi-squared.com / @tonymi2
oemr.org / @OEMR_org
sunsetsystems wrote on Saturday, November 26, 2011:
Agree that creating modular methods/standards to satisfy custom needs is a good thing, and a way to encourage more contributions to the code base. This is another area where donations (grants, etc.) towards infrastructure work would be valuable. For new development, suggestions for this kind of refactoring should be made at code review time where appropriate.
mdsupport wrote on Saturday, November 26, 2011:
Quick example of what was suggested in earlier post -
Current code in left_nav.php is a collection of if blocks
require_once("../globals.php");
...
standard menu-item1
<?php if (!$GLOBALS['ippf_specific']) { ?>
ippf_specific menu-item2
<?php } ?>
standard menu-item2
...
Consider this option:
require_once("../globals.php");
include_once("../localized/left_nav_begin.php");
...
standard menu-item1
standard menu-item2
...
include_once("../localized/left_nav_end.php");
Only ippf installations will have the following 2 files which would not be part of the standard release but could be provided from an add-on library:
localized/left_nav_begin.php
<?php if (!$GLOBALS['ippf_specific']) { ?>
standard menu-item1
ippf_specific menu-item2
standard menu-item2
<?php } else { ?>
localized/left_nav_end.php
<?php } ?>sunsetsystems wrote on Saturday, November 26, 2011:
The IPPF case is not a good example of customization for a particular user, as it represents family planning clinics worldwide (and the flag name name would better be something like “family_planning_specific”). But I do understand the point that some users will want custom features with corresponding menu items.
Another approach, more user-friendly, might be to put the menu structure and items in the database, much as was done for lists and layouts.
mdsupport wrote on Sunday, November 27, 2011:
Rod is correct. The example was chosen from the first file that came to mind for its simplicity - menu needing custom items where entire menu can be replaced by a custom menu. We use the same approach for process as well as UI customization. Process customization code is bit more longer to post here.
An example of a simple process customization that we have implemented is after patient check-in from appointment screen, user is presented the billing screen to accept co-pay and other balance due. Should this be OpenEMR standard process? Probably not. But it will be worth for many practices in US to try. With the ‘include-once’ approach, a practice can try this change by copying a few files. If it does not work, delete the ‘localized’ files and the php compiler will make sure the process reverts to standard. Most importantly, there is very little effort needed once the minimal code changes are made to the standard scripts.
Process customization will be even bigger issue as the application goes mobile. The steps/screens to be followed in office are not necessarily best suited as the same physician is following up on the patient in the hospital. So it may not suffice to make office EMR available everywhere to the physicians.
The bigger point is this project’s success is going to be driven by the number of ‘skins’ it offers out of the box. Ideally the install will process will ask the type of specialty, country etc… So when installed for a Gyn practice, the installation would have Gyn forms and Gyn processes ready-to-go.
Apologies to Brady for this post in rather unrelated topic.