Release 4.1 Planning

bradymiller wrote on Wednesday, July 27, 2011:

hi,

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

For those that are curious, here’s some documentation on release process:
http://www.openmedsoftware.org/wiki/Steps_for_an_official_release

Also, here’s where we’ll compile the list of new features (please feel free to start filling this in):
http://www.openmedsoftware.org/wiki/Release_Features#Version_4.1.0

And here’s the copyright/contribution page (please feel free to place your name/info here if you’ve contributed any time into the project):
http://www.openmedsoftware.org/wiki/OpenEMR_Copyright_Notice

Of course, decision to release and when are up to the community. Just figured it’s time to start getting the ball rolling.

-brady

tmccormi wrote on Thursday, July 28, 2011:

Seems like a good time line to me.
-Tony

yehster wrote on Saturday, July 30, 2011:

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.

bradymiller wrote on Saturday, July 30, 2011:

Hi Yehster,

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).

Also, not all code gets reviewed. Simple bug fixes or code from Privileged Developers (http://www.openmedsoftware.org/wiki/Repository_work_flow_structure#Privileged_Developers_2 ) that feel the code has been adequately tested and does not need review(this is pretty uncommon for larger modules).

-brady

bradymiller wrote on Saturday, August 13, 2011:

hi,

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 takers? :slight_smile:

-brady

arnabnaha wrote on Saturday, August 13, 2011:

What about not able to incorporate the rxnorm and snomed database in windows??

bradymiller wrote on Saturday, August 13, 2011:

That will be item number 17 :slight_smile:
17) Fix bug for Windows path for the rxnorm and snomed database import feature.

zhhealthcare wrote on Saturday, August 13, 2011:

Brady,

If you need any assistance we would be glad to help.

Shameem

mike-h30 wrote on Saturday, August 13, 2011:

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.

**Clone previous fee sheet **
https://sourceforge.net/projects/openemr/forums/forum/202505/topic/4497380

**Linking Codes to Issues to Fee Sheet **
https://sourceforge.net/projects/openemr/forums/forum/202506/topic/4043422

Mike

uhsarp wrote on Sunday, August 14, 2011:

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!?

bradymiller wrote on Sunday, August 14, 2011:

hey,

Committed fixes/features to sourceforge for items 1,2,6,7,and 15 above and a CDR bug involving multiple target group ids.

Goal is to branch off to a rel-410 branch be the end of this week (and then release 4.1 about 2-3 weeks after this).

In order to accomplish this, will need some help.

Since your offering to help Shameem, here are features/bug fixes that your group could likely efficiently deal with(let me know what you guys can do to help for planning):
1) Your portal (I’m aware I’ve been the bottleneck there, but we should be able to get it in by the end of the week)
2) Confirm arnabnaha email/fax bug fixes work on linux :
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/4654734
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/4654703
3) Attempt to fix bug for Windows path for the rxnorm and snomed database import feature described here:
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/4599543
4) Look into and attempt to fix this bug for immunizations:
http://sourceforge.net/projects/openemr/forums/forum/202506/topic/4626402

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.

-brady

acmoore wrote on Sunday, August 14, 2011:

… 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.

-Andy

blankev wrote on Sunday, August 14, 2011:

There must be someone in the group of OEMR that can give form to something with capacity as for example:

Who am I, what is the interest in OEMR, what do I do with OEMR, what did I add to make OEMR till what it is today.

Could even be something with an adjustable grade of very much => very little interest.

All with automatic login with something like thumbs up or down, if ap-/disap-proved by members……

FB but with special interests for the OEM development and user (community) with search capacity and sorting.

Pimm

zhhealthcare wrote on Sunday, August 14, 2011:

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.

Shameem
www.zhservices.com 

uhsarp wrote on Sunday, August 14, 2011:

@acmoore

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)…

jcahn2 wrote on Sunday, August 14, 2011:

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

jcahn2 wrote on Sunday, August 14, 2011:

Oh yes,
The fourth item would be a pswd to facilitate email with pswd logins for repeat downloading.
jc

bradymiller wrote on Sunday, August 14, 2011:

Hi,

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?

-brady

bradymiller wrote on Sunday, August 14, 2011:

Hi,

For 4.1, we should also deal with these recently published OpenEMR security exploits:
http://packetstormsecurity.org/files/103810

-brady

bradymiller wrote on Wednesday, August 17, 2011:

Hi Shameem and Tony (and everybody else),

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.

thanks,
-brady