We are about to get up to 4 e-RX solutions offered to this community for OpenEMR. We do not have a good structure to support competing solutions. I would like this to be possible. Sadly the solutions providers are not allowed to discuss the details with each other in some case (e-RX vendors require strict NDA).
There may be options. The obvious, and safest, one is to branch OpenEMR for each variant. This puts the burden of keeping a particular vendors offering merged with the main line release and future development squarely on the Vendors shoulders. But means extra work in packaging and downloading for the communities (hmmm…) highly paid staff
The pile-of-if-statements model is not a good one, in my opinion, but is here for the sake of argument.
Rearchitecting OpenEMR to use include-able modules (plug-ins) would be best but would require a fork and funded redesign. Not going to meet the time lines for reasonable releases, I don’t think.
Is there a way within the restraints of the NDA’s to simply identify which files in the “main branch” of OpenEMR the e-RX solutions are going to impact?
Hopefully the e-RX solutions are primarily additions of files, with only limited changes to the existing files. If the changes required are simple, like simply using a different URL from the prescriptions link on the demographics page, it might not be so bad.
Sadly not the case, major changes in all the places that are touched by medications, prescriptions, allergies including the table formats and support for things like Rx renewal proceessing. All of these differ from solutions to solution. Some call out to web resources using XML messaging and retrieve data that needs to be stored locally, some don’t. AND we need to not step on the built in RX modules that support paper RX and in house pharmacy… very complex this is.
Tony,
The history of OpenEMR is both a good and bad thing. From the beginning, the data base structure has worried me - enough so that at first I wrote off the whole project. (A separate column for smoking status?) But the amazing ability you have shown in pulling together a certification is absolutely incredible. Merging the old code base on top of the new requirements - keeping users happy, hard to beat. But refactoring is inevitable. Why not start creating the new modules based on a design that allows future improvements. Create a temporary structure to hook in these modules and then make new development on a new base that at first duplicates , then slowly replaces the old structure.
D
Olympia, Wa
Knowing how convoluted the EMR structure is, and how you have to search the includes of includes of includes of includes to find all the code that runs a feature, I can understand this, but let’s think about it.
The EMR runs fine without having prescription, in-house pharmacy, labs or anything else toggleable in globals.
Why is it so hard to use separate sets of modules without a total re-structuring? Sure, the project needs that approach, but can’t added modules just get a set of flags in globals (which in turn would be driven by an include or database addition to indicate what modules are available much like forms admin)? The built-ins ARE flaggable already, right?
If enabled, a modlue use could transformations/reassignments to turn “standard” variables into their own and vice-versa, preventing corruption of standard features, and use all their own modular tables for other data, right? Couldn’t script and lab interfaces just take you outside the box a bit to their own code, and then simply use their own tables/ DB as well as reading/writing to the “standard” DB or tables that are used for demographics, history, vaccines, calender and the like?
Personally, I like being able to turn off features that we don’t use. I’d like to have the option to snuff out every bit of code that we don’t use too. I also wouldn’t want to visit 4 different branches to make a mod or add-on.
Gotta be a way that the controller can handle fairly wide-ranging questions about where it goes from the nav bar to decide what files to use. I see such “add-ons” as being outside modules that handle all their own displays etc… and only communicate to the rest of the EMR. Run it as a “site” maybe?
CDR and AMC API and framework basically follow the “all new” model, object oriented MVC framework. JQuery allows you to “wrap” an external .php output so that in is encapsulated in a <div> tab or window. What we need is a hard core proposed structure to put add-on modules in and a standardized way to find them. The Forms control tool has the general idea. Drop a set of code in a known place and a tool let’s you optionally install and activate the parts. LBF is flexible forms that don’t have to be ‘encounter’ based and could be ‘displayed’ anywhere. Layout of these forms is somewhat limiting but might work anyway.
Certification (ie PQRI reporting) will need to know how to get the data for the reports so that adds complexity to any overlay scheme.
Perhaps even the tables could be overlayed, as in addonname_prescriptions, addonname_lists get’s used if they exist and the “addonname” is installed?
Tony
Why don’t we have each of the provider’s have a different patch which can be downloaded per users choice? Links to the patch download given on the wiki or sourceforge. Whoever decides to use a specific solution runs that patch. Is it necessary to bundle the solution with the product?
I don’t suppose any of the e-Rx vendors would care to open source their code in exchange for being the primary e-Rx solution that is hard coded into OpenEMR. Each is turning a profit on their unique SureScripts interface/access now, but one day this stuff will all be free like your online banking. So who will they sell their access to then? Like Tony, just thinking aloud. Jack
hi,
I’d suggest coding it like all the other projects (ie. incorporate it in a OpenEMR friendly manner). The actual mechanism (ie. object-oriented, procedure based, etc.) can be left up to the development group whom code/designs it; main objective should be that it’s OpenEMR friendly (meaning it does not break current features, maintains current security standards, is upgradeable for previous users, etc.). To create forks/branches when we can barely maintain our main one and previous version patches doesn’t seem like a real feasible option. Also, OpenEMR vendors should be motivated to get their e-rx solution into the main codebase anyways to ensure it gets supported by the community (ie. not broken by new features/enhancements).
-brady
As far as I can understand, you are hinting in the direction of something like what C-Panel is for easy web design on a Server. Test and test and test, if you like it, you use it , Testing the nicest software ytou really need. Decide after experience of the software if you want to use or after testing, or after testing be sure never ever want to test it again and delete it from the your website…
