anonymous wrote on Wednesday, December 30, 2009:
Seems a bit overly complicated (redundant and inflexible) to start with, why not do this in pieces?
> Basically, we are addressing CDR as one integrated module so that we can take care of the relationships between different parts. We have worked with much bigger systems, so this is not complicated at all. We are breaking down the module into different pieces of work.
Confused on your naming. for your flu shot shouldn’t it be category->health maintenance sub-category->vaccinations plan_name->flu shot.
> We are using your suggestion in clinicalreminder table. The items highlighted in blue are the same examples as yours.
Why map with the id? Why not use the name to avoid problems when users customize stuff and to data is discrete (ie. there will also be a flu shot for diabetes).
> There are a number of reasons. For patients, we know that the mapping cannot be done using patient names. Some tables don’t have names. So the first reason is to be consistent in our mapping. From a database perspective, the smaller the key, the better the efficiency. That’s the second reason.
Also, why hard-code all of the possible code columns? (what happens if user wnats to use a SNOMED code) When not just make a ‘code’ column and put them all there (cpt:??? icd:???) etc…
> The reason is that there will be multiple entries in each code column. If we attempt to mix the 5 different code fields (together with their multiple entries), it will be much harder to manage.
Also question all the patienthistory and lababnormal columns? Can’t this simply be added later after you get the basics working (at that point another mechanism may make more sense).
> Patient history is where Smoking Cessation comes in. So we are addressing it here. It’s the same idea as yours. As for lababnormal, this is included because we are also working on Lab Test Results. Obviously, it can be separated too. It’s included because we are looking at the work as an integrated module. This helps us avoid missing critical components. We won’t and can’t code everything at the same time.
Also, where are the target frequency or age columns in this table?
> The target frequency is not needed because each reminder is for a specific plan action. So the frequency is built into the action. A plan without an action doesn’t do any good. As for the age columns, see age_from and age_to. We like to match table field names with the corresponding GUI labels. They can be renamed.
I’m also confused why patient’s need to enroll in plans, if your gonna have all the inclusions/exclusions, then might as well make every rule pertinent to every patient. As a physician, we shouldn’t need to to enroll patients (should be automatic via database data, icd9 codes etc.)
> I think the patient has a right to accept or refuse a plan. So yes, the system can default every patient to a number of health plans. But each patient can opt out due to a number of reasons. There will always be exceptions.
Also seems better to focus on the rules portion before creating the reminder/messages part. With a good rules database structure and simple algorithm you can spit out the reminders in real-time (in the patient summary screen) and have a real-time mechanism to deal with them. You can then take advantage of this algorithm in your message/reminder stuff.
> We are addressing CDR as an integrated module but will work on the different parts according to their priorities. In this case, we will start coding for the rules first.