bradymiller wrote on Sunday, September 19, 2010:
hey,
Been working on this off/on lately. It’s starting to look pretty cool, but still way early in alpha phase. I’ve posted most recent patch(and github branch) and details here:
http://sourceforge.net/tracker/index.php?func=detail&aid=3055162&group_id=60081&atid=1245239#
If so desire, feel free to test/review and provide input.
-brady
ellisbjohns wrote on Monday, September 20, 2010:
Brady,
I’m new to your project, but I’m curious if you’d be up for using a clinical decision engine currently being developed (openCDS), but based on a working clinical decision engine web service called Sebastian. Dr. Ken Kawamoto developed it a few years back and I"m currently implementing it for Harvard’s Dana Farber Cancer Institute. OpenCDS will be promo’ed at the upcoming American medical informatics association’s (AMIA) annual conference in DC this November. Also, I’m currently on the development team for OpenCDS, and various aspects of the decision engine are set to become an HL7 CDS standard. It is based on the drools rules engine, and coupled with the guvnor editing platform (completely open source).
Let me know if you’re interested. I don’t see much sense in re-inventing the same wheel. Especially since we’re both working on open source HIT tools.
Ellis, MD, MSIS/CS
Post-Doc Duke Clinical Informatics
bradymiller wrote on Monday, September 20, 2010:
Ellis,
Looks very interesting. Is the code for openCDS available?
thanks,
Brady
ellisbjohns wrote on Monday, September 20, 2010:
Brady,
It will be, but probably not until after the AMIA conference (We don’t want to open source unrefractored code). Currently, we’re using a subversion repository on our dreamhost server (openCDS.org), but we’re in the middle of moving the code to something that requires less maintenance and is more accessible. Any suggestions? I looked into the open source packages for gforge and assembla, but perhaps we should stick with something simpler like source forge.
Looking forward to working with you,
Ellis
bradymiller wrote on Tuesday, September 21, 2010:
Ellis,
Will look forward to the code when released. Regarding a public repository, there are a lot of choices. Although it’s not shiny and has some issues (tracker is kind of a pain to use), can’t really go wrong with sourceforge; about a year ago here, the repositories became pitifully slow, however this was fixed about 6 months ago. Pretty much no maintenance for the admin’s except to add cvs/svn privileges, which is very easy. Something that has really helped us is to create a one-way git mirror on github (mirrors the sourceforge CVS repository every 30 minutes). This gives developers that know git a lot of flexibility; I actually code 100% in git repo now and it’s very easy to commit patches to the sourceforge cvs from my git repository. We contemplated making our main repository in git, but decided not a good idea (to easy to destroy code). To illustrate github, check out my github repository:
http://github.com/bradymiller/openemr
And for a tutorial in git (written with goal of getting openemr developers proficient as quickly as possible):
http://www.openmedsoftware.org/wiki/Git_for_dummies
-brady
bradymiller wrote on Thursday, November 18, 2010:
hey,
Next alpha testing release of the clinical decisions engine can be found here (explanation can be found in the commit
comments):
http://github.com/bradymiller/openemr/commits/rules_11
-brady
rnagul wrote on Monday, November 22, 2010:
Hi,
I am new to the project. Been in touch with Tony. What is the best way to get started on the clinical decision engine?
bradymiller wrote on Tuesday, November 23, 2010:
hi,
Welcome to OpenEMR.
Just released a new milestone (still in alpha stage) commit for this project on my personal github repository here:
http://github.com/bradymiller/openemr/commits/rules_13
As I continue to work on it, will place additional code here:
http://github.com/bradymiller/openemr/commits/rules_14
The best way to get started is to test the code out. To do this recommend you set up a personal git development repository, which makes it very easy to test (and contribute to) code that’s in development. We have a easy to follow tutorial on setting up and using a personal git repository with OpenEMR here:
http://www.openmedsoftware.org/wiki/Git_for_dummies
The current commit details that describes this code is the following:
Interim development of a clinical decision making engine.
Engine depends on rules, filters, targets, and actions. Basically,
if a patient fits in the filter, and the target(s) is false, then the
action(s) happens. The current scheme allows one filter
and multiple targets and actions per rule, is very flexible, and supports
internationalization. Engine is used for clinical decision support,
clinical quality measures (CQM) and patient reminders.
FUNCTIONALITY:
1) Clinical Decision Support widget can be found in the top right
of the patient summary screen.
2) CQM report can be found at Reports->Clinic->Quality Measures.
3) Clinical Reminder pages can be found at Administration->Patient
Reminders and Administration->Patient Reminders Batch (note still
working out some bugs in these two scripts).
TODO:
1. Finish rules for the 10 CQM rules (will likely require some
algorithm adjustments to deal with the encounter types and
frequencies that are used in the CQM rules).
2. Ensure NIST is accomplished for CQM and clinical decision support.
3. Work out some bugs in the patient reminders (may ask Visolve to help
with testing the modified mavix scripts)
4. Ensure NIST is accomplished for the patient reminders.
5. Add a mechanism to allow full per patient modification of the rules.
6. Add mechanism to allow multiple filters per rule.
7. Add a admin gui(s).
8. Add a mechanism for plans.
FILE MODIFIED:
interface/batchcom/batch_phone_notification.php
interface/batchcom/batch_reminders.php
interface/main/left_nav.php
interface/patient_file/reminder/patient_reminders.php
interface/patient_file/rules/patient_data.php
interface/patient_file/summary/clinical_reminders_fragment.php
interface/patient_file/summary/demographics.php
interface/reports/cqm.php
library/clinical_rules.php
library/forms.inc
library/globals.inc.php
library/maviq_phone_api.php
library/patient.inc
library/reminders.php
modules/sms_email_reminder/batch_phone_notification.php
modules/sms_email_reminder/batch_reminders.php
sql/database.sql
Code’s rather complicated, so definitely feel free to ask any questions.
-brady
bradymiller wrote on Friday, November 26, 2010:
hey,
Next milestone release can be found here (still in alpha):
http://github.com/bradymiller/openemr/commits/rules_15
Additional commits before the next milestone release will be placed here:
http://github.com/bradymiller/openemr/commits/rules_16
Fixed lots of bugs, improved Clinical Reminder widget, and also added a PAtient Reminder widget. Commit comments include the following:
Engine depends on rules, filters, targets, and actions. Basically,
if a patient fits in the filter, and the target(s) is false, then the
action(s) happens. The current scheme allows one filter
and multiple targets and actions per rule, is very flexible, and supports
internationalization. Engine is used for clinical decision support,
clinical quality measures (CQM) and patient reminders.
FUNCTIONALITY:
1) Clinical Decision Support widget can be found in the top right
of the patient summary screen.
2) Clinical Reminder widget can be found in bottom left (above vitals
widget) of the patient summary screen.
3) Clinical Reminder page can be found at Administration->Patient
Reminders. The batch to send the messages can be run from this script
by clicking the Send REminder Batch button.
4) CQM report can be found at Reports->Clinic->Quality Measures.
TODO:
1. Finish rules for the 10 CQM rules (will require algorithm adjustments
to deal with the encounter types and frequencies that are used in the
CQM rules).
2. Ensure NIST is accomplished for CQM and clinical decision support.
3. Get the email and voice patient reminder mechanisms to work (may ask
Visolve to help with testing the modified mavix//voice email scripts).
4. Ensure NIST is accomplished for the patient reminders.
5. Add a admin gui to allow per patient customization (note the
mechanism to do this already exist, so just need a simple gui for it)
6. Add mechanism to allow multiple filters per rule.
7. Add a admin gui to allow rule modification and creation of new rules.
8. Add a mechanism for plans.
bradymiller wrote on Wednesday, December 08, 2010:
hey,
This projects is picking up steam. Now several developers will be working on this simultaneously, so can no longer rebase the code into nice easy to read commits. For now on, will maintain the development of this module here:
https://github.com/bradymiller/openemr/commits/rules_develop
New commits to this branch will be announced in this forum and here:
http://sourceforge.net/tracker/?func=detail&aid=3055162&group_id=60081&atid=1245239
-brady
bradymiller wrote on Wednesday, December 08, 2010:
hey,
Added initial support for “Automatic Measure Calculation” Meaningful Use item. The clinical
rules engine should be able to handle these calculations relatively
easily.
http://github.com/bradymiller/openemr/commits/rules_develop
-brady
bradymiller wrote on Wednesday, December 08, 2010:
Stephen,
Was hoping to get some git-guru input here. The above rules_develop branch will likely not be part of the official sourceforge master branch for 1-2 months. What is th best way to keep it uptodate with the sourceforge master branch? My plan was to merge the sourceforge master branch every week or so (which will create a merge stub along with some required conflict resolution). I just want to make sure there are no problems when I then want to merge this development branch into sourceforge master in a couple months (ie. will the numerous merge commits from sourceforge master with conflicts fixes screw things up?)?
thanks,
brady
sunsetsystems wrote on Wednesday, December 08, 2010:
Brady, go ahead and put the stuff in the SF master branch. Add a global switch to keep experimental code turned off by default, and of course some logic in places like left_nav.php to support it. No sense in creating a future merge headache for yourself. This will work if everyone is careful to write conditional code where it matters, and since most of it is in new modules it won’t matter in many places.
One special concern would be the database changes. Those could go into their own sql file temporarily.
bradymiller wrote on Wednesday, December 08, 2010:
Rod,
There won’t be any merge headaches (as long as Stephen thinks my above plan is ok). When I merge sourceforge master into the development branch the only potential conflicts are in several places and easily adjusted via git.
About half of the rule engine code is actually the database, and this will be in major flux as add support for the Clinical Quality Rules, Automatic Measure Calculation, and other functionality. By keeping this separate from official codebase means there is no overhead when modifying the database stuff (note I don’t even maintain changes in the sql upgrade script yet because would take too much time to change it every time i modify the database.sql file.) If it was in the main codebase, then too many resources would be wasted on “upgrading” the database stuff for users that decided to implement it (I still predict a large amount of database mods will need to happen before code is ready).
Basically, the time for me to maintain a development branch for this code is far less than the time required to “maintain/upgrade” this code in the official sourceforge codebase for now. When code is stable (ie. the database footprint is stable), then will make sense to bring it into the main codebase (realistically that is 1-2 months away)
-brady
sunsetsystems wrote on Wednesday, December 08, 2010:
OK, up to you. just want to make it easy for everyone and keep development focused on one code base. Development becomes more difficult when one has to look in other places to keep up with current efforts (I’m thinking here about developers NOT working on the CDE). This is more of a concern with lengthy projects, and “1-2 months” is a big red flag to me in that regard.
See ippf_upgrade.sql for an example of what I man about separating the database changes.
bradymiller wrote on Wednesday, December 08, 2010:
Rod,
To ease your mind, this is for code development specific to the clinical rules engine. Look through the changes I have in database.sql of this code; very extensive and the database footprint can change dramatically every several days (ie. yank a table, modify a table, add a table, add a list_options, modify a list_options etc.). Rather than endure the tedium of worrying about end-users using this code (ie. considerations of database upgrade scripts), would rather focus on continuing to optimize the database footprint with no other hassles.
This will be a project specific branch that will leverage the power of git (ie. distributed development) as long as Stephen doesn’t see any issues with the plan. No fork will happen because I will merge in the sourceforge master into it every week (will only take about two minutes to fix the predicted conflicts); and when it’s ready will then merge this module into the sourceforge codebase (this merge should then also be hassle free).
-brady
sunsetsystems wrote on Wednesday, December 08, 2010:
Yes I know, I did briefly look over the commits before posting. 
Thanks.
stephen-smith wrote on Wednesday, December 08, 2010:
bradymiller
Was hoping to get some git-guru input here. The above rules_develop branch will likely not be part of the official sourceforge master branch for 1-2 months. What is th best way to keep it uptodate with the sourceforge master branch? My plan was to merge the sourceforge master branch every week or so (which will create a merge stub along with some required conflict resolution).
Feature branches shouldn’t have mainline development merged into them. Here’s what Linus says about that type of workflow: “But if I see a lot of ‘Merge branch linus’ in your logs, I’m not going to pull from you, because your tree has obviously had random crap in it that shouldn’t be there…”
bradymiller
I just want to make sure there are no problems when I then want to merge this development branch into sourceforge master in a couple months
The longer you have two branches the larger the list of conflicts will be. There’s a number of ways of reducing the scope of changes that you have to deal with all at the same time. I believe the kernel has gotten into the habit of using {git merge mainline; (if conflicts, fix and commit); git reset -hard HEAD^;} to load up the “rerere” cache so that rerere handles most of the final, recorded, large merge. I use a process and script I made up to weave together an “integration branch” that consists of nothing but merge commits; in roughly a 1:1 ratio with conflicts.
Both these techniques keep both mainline and the feature branch “clean” during development. The kernel method tracks conflict resolution is a rather hidden and non-shared way, and puts all the “dirt” into one merge commit for when the branches come back together. After that, the commit history looks quite simple. If any problems get introduced by the merge, they all get tracked to that single big, “dirty” commit.
My method tracks conflict resolution in a public and shared way and has a separate commit for each piece of “dirt”. Unfortunately, at the end the history looks very complex and has a lot of merge commits. If any problems get introduced, they can often be tracked down to a very small, “dirty” commit.
Regular merges from master is fine for us. Having the feature branch be “clean” isn’t that important, no one is too familiar with rerere, and most of the team is still trying to get comfortable with what a merge commit is.
bradymiller
(ie. will the numerous merge commits from sourceforge master with conflicts fixes screw things up?)?
Some people/ don’t like merge commits. Git is very good at handling them. Multiple merges from master won’t “screw up” Git. It also shouldn’t affect our existing workflows adversely. The only thing I can think that it makes more difficult is separating just-this-feature from general-4.0-development, but I’m not sure that’s a goal for us now. The recommended workflows on the wiki make that hard-to-impossible already.
stephen-smith wrote on Wednesday, December 08, 2010:
5 good articles about Git workflows in general, and feature branches in particular that I found while looking for a succinct answer to your questions:
bradymiller wrote on Thursday, December 09, 2010:
Stephen,
Thanks for the detailed explanation and links.
“Feature branches shouldn’t have mainline development merged into them.”
It seems that Linus quote in your above post was directed to developers who were merging from mainline with no good reason (ie. just the anal need to keep code updated). The maintainer of git describes a more reasonable approach here: http://gitster.livejournal.com/42247.html (basically, it’s ok to do if your feature needs to work with code found in more recent mainline code). I agree, though, that a weekly master->rules_develop merge would fall into the anal category and is not necessary. I’ll instead do a merge from master->rules_develop only when needed (ie. need to get the CDR module to work with a new feature in master).
"The only thing I can think that it makes more difficult is separating just-this-feature from general-4.0-development, but I’m not sure that’s a goal for us now. "
This is related to my next question. Once I merge in master, is there any way to derive a patch file from just the feature (to allow other developers to read/review the new feature). For example, I can now force a diff in: https://github.com/bradymiller/openemr/commits/rules_develop
with the following command:
git diff 1dc940d59c66e233a8f8f48486cf82f7daf938c4…rules_develop patch
Will I lose this ability after merging from master?
thanks,
Brady