Since we’re likely gonna have full certification soon, figured it’s a good time to start thinking about a release. My thought were the following:
a) 2 more weeks of features (several on the brink of getting committed and also several CDR engine things that need to be finished up)
b) then branch off for 3 weeks of testing/bug fixing before the final release
Something I’m trying to figure out is where and how the discussion of code changes/reviews is taking place these days? There are a lot of pushes into the master branch, but not many posts here in the forums.
Generally, reviews/commits are requested on either the forum or on the tracker (I “watch” the project (button at top right of the sourceforge pages) to ensure I see this stuff). Recommend doing that if you want to participate or follow the reviews (which would be awesome).
Considering the imminent full certification, time to consider starting the testing clock soon. Here’s my wishlist of features/bug fixes to get in 4.1:
1) Implement Active Reminders in CDR (popup once when open patient) (I will do this)
2) CDR procedure/allow incorporate code or title use. Also ensure can be used as both a filter/target.
3) CDR GUI - implement plan/rule mapping
4) CDR GUI - allow adding lab/procedure filter/target
5) Update translations (add the CVX immunization items(both short and long))
6) Update ubuntu package (I am almost done with complete refactoring of this package to ensure works well with ubuntu 11).
7) Place the missing reminder tables into upgrade script that did not seem to be added in the 3.0 upgrade.
8) Add translation choice option (use same mechanism as normal login) to the patient portal.
9) Incorporate RxNorm codes into the prescription/med list stuff.
10) Fully integrate the prescription/med list
11) Add a code_types ct_label column and incorporate this. See the Code Types wiki page for details.
12) zhhealthcare portal
13) The weird patient id bug (“Clinical Reminders seems to require that $_SESSION (which becomes $pid) be a string value. It fails if the value’s type is integer.” and shows all rules.(very bad bug))
14) immunization bug (report that immunizations reported before a 4.0 upgrade are not showing up)
15) Some minor PQI report bug fixes by visolve (just need to be committed)
16) A very odd, but nasty CDR/mysql bug reported by visolve
Any chance to add a feature to enhance billing with the fee sheet by eliminating the redundancy of having to enter the same CPT codes again and again when billing patients that are seen for the same diagnosis on a regular basis? Here are a couple of related posts.
I can contribute XAMPP package after release. Also any plans to move to Full CSS from frames and a voluntary OpenEMR user submission guided by a privacy policy? This is to have an active list of OpenEMR users maintained by OEMR with a privacy policy agreeable by everyone in the community (I’m not sure if one is needed! but at least it would make it comfortable for people to fill the form). I’m not sure why this is unable to find any traction in the community!?
There are two features that we should try to get into the Admin GUI for the CDR module. Ken is the most proficient in this framework, and was hoping he would take this on (Ken, to help with our planning, please let us know if you can do one or both of these):
1) Implement plan/rule mapping in the Admin GUI for CDR. Note this simply involves creating a screen that allows mapping of rules to plans via the ‘clinical_plans_rules’ mysql table (as the other rules, do not show or allow mods of the cqm rules and plans)(also, note that a rule can be in multiple plans). This would be an extremely useful feature for little time, and allows physicians to view rules by plans in the Patient Summary Clinical Reminder widget Edit button (Plans tab).
2) Implement procedure filter/target creation in the Admin GUI for CDR. Note the CDR engine currently supports this (see the Coumadin rule for an example) and this feature is gonna be in high demand for users that want to create rules via the Admin GUI that involve procedures.
I plan to fix several more CDR engine bugs, add the CVS immunizations terms to the translation engine, and provide a Language selector in the onsite portal,
We probably won’t be able to get to better integration of Medications/Prescriptions and incorporation of the RxNORM database into these elements within OpenEMR for the next release; unless somebody else steps up to do this. Same for Mike’s request unless somebody steps up to do this.
… a voluntary OpenEMR user submission guided by a privacy policy? This is to have an active list of OpenEMR users maintained by OEMR with a privacy policy agreeable by everyone in the community
I’m not sure I understand this part. Is the goal here to assemble a list of openemr users?
If so, would a wiki page suffice? If you use openemr, then you can edit the page to add whatever contact details you would like to.
I can’t imagine any form becoming very complete, but at least it may collect some example clinics and practices, I guess.
Brady
I’ll have my guys look into the points you mentioned. Will revert to you on that.
On the other point of collecting info of openemr users, We need to have some form of data when we go to get grants or such other things. Why cannot we have people fill up a form if they have to download? The form can collect basic info like speciality, profit or non profit and an email address. Once they do this they can be send an email link to download. Or a security code to begin installation.
I’m not sure I understand this part. Is the goal here to assemble a list of openemr users?
Yes but I’ve seen that the product registration form works better than the WIKI form, And also since only OEMR receive the info as per a pre agreed privacy form, OEMR can publish statistics like no. of users of OEMR, users in 2011, no. of non-profits using OEMR etc. And users will be comfortable to send their basic usage info as only OEMR will handle the data if they wish to keep it private.
@zhhealthcare
On the other point of collecting info of openemr users, We need to have some form of data when we go to get grants or such other things. Why cannot we have people fill up a form if they have to download? The form can collect basic info like speciality, profit or non profit and an email address. Once they do this they can be send an email link to download. Or a security code to begin installation.
I like the idea and I’ve seen it in action at Mysql.com and others but can we force users to fill out a form every time they want to download and how will the licensing restrict our ability to do so? Or make it optional to fill the info before the download page and also include a registration form after/during install (below “Online Help” button in the left menu panel or something like that)…
Ahoy,
The privately protected collection of name, email and role is a good idea, which really should not deter anyone who is seriously interested in downloading OpenEMR, and clearly would identify unique downloads form repeats. Would/Could we also include a link encouraging oemr.org membership at the free “user” level?
Jack Cahn MD oemr.org BOD
Although not relevant to the 4.1 release, regarding registration:
There are about 100-130 downloads a day, which will mostly just be people trying out the software. Forcing user information before download will likely have a negative impact on the downloads, will require an infrastructure to be built to do this, and will likely collect a lot of noise (ie. lots of users whom download/test but do not use in practice). Wouldn’t a online registration form offered after installation of OpenEMR make more sense, which could then discuss the oemr membership stuff also?
Was hoping to get the status on my proposals above (ie. can you do it and if so, approximately when) so I can figure out when to set aside some time to branch the code and build a specific 4.1.0 development demo and daily testing packages(would like to do at end of this week if possible).
After the branch/demo are done, will likely plan a release about 2 weeks after that if things are looking good.