anonymous wrote on Sunday, December 20, 2009:
Greetings, here’s what we have envisioned regarding the various components of Clinical Decision Support. Please review and share your ideas. Thank you.
bradymiller wrote on Sunday, December 20, 2009:
hey,
Another great project and would be a great feature to have. Here’s the link above with proper formatting (Have I said lately how I hate this forum’s insane formatting):
http://www.openmedsoftware.org/wiki/Clinical_Decision_Rule
My initial thoughts are how to set up the database. Will be interesting to get Rod’s thoughts here also, and anybody else who wants to speak up; it’s always better to get lots of other viewpoints. I’d set up two database tables, one to hold the clinical\_reminder rule and the other (clinical\_reminder\_map) to map a rule to a patient and hold the date(s) it was completed and the results if applicable.
<pre><code>clinical_reminder table with following columns:
id (unique for each rule)
active (allow turning off/on rule without needing to remove from database, which is important to keep mapping accurate)
category (to allow grouping of rules, ie diabetes)
sex (if male or female specific)
code (if based on icd9 code or other dx coding)
age_low (if based on age, put low end here)
age_high (if based on age, put high end here)
frequency (frequency of rule required, use values only and standardize to months)
</code></pre>
<pre><code>clinical_reminder_map table with following columns:
id_reminder (id from above clinical_reminder table)
id_patient (id from patient_data table)
date
result (i’m on the fence whether this is needed?)
</code></pre>
This structure would allow holding rules and option to filter for age ranges, diagnoses, and sex. Also would allow categorizing the rules for easier organization. Then if a patient “completes” a rule they get an entry in the mapping table with date it was completed. Plus, it would work with internationalization since no english language is required in any entries (I’d suggest mapping the category column and sex column to a list in list_options to make compatible with internationalization; very easy to do this)
I agree with the admin clinical reminder page, where you could import (note you’d never want to remove rules from the table because you always have to have the mapping id’s stable; which is why need the active flag column) and export of rules, manually set rules, and otehr modifications. (all would be supported by above table structure).
I’ve been lucky to see the new gui refactoring demo that Tony is working on, so I would suggest putting clinical reminders right below the DA section in the demographics summary with it linking to a pop-up for the user page (to enter if something has been done). For this widget in the demographics summary you’d simply do a sql-query of your patient through all the possible rules and shows the ones that apply (along with last date completed and/or is now due).
Regarding automatic reminder creation (such as mammograms), could have a script that simply checks the database daily and spits it out however format you want.
-brady
blankev wrote on Sunday, December 20, 2009:
Could this also be the place for medicine interactions? I suppose, once implemented, it can hold some some automatic flag for Yes/No “this medication”, for “age” and/or “gender”.
For this last remark the medications should be grouped, as in many Database for medications, like the working group of European Medication or the WHO or some other International group busy with classification of medication.
Pimm
bradymiller wrote on Sunday, December 20, 2009:
Pimm,
The wiki page is here:
http://www.openmedsoftware.org/wiki/Clinical_Decision_Rule
If your ok with it, I’m gonna delete the ClinicalDecisionRule page you just created.
-brady
blankev wrote on Sunday, December 20, 2009:
Defenitiely OK with me!
Looks great and I was just importing any comments on this topic that seemed to be some kind of explanation of what is going on.
But this/your “manual” is what should be there.
TNX!
Is it working in Developer 3.1 or do I have to open 3.2 Demo?
Pimm
anonymous wrote on Monday, December 21, 2009:
Hi Pimm,
Thanks for your feedback. I’m trying to get as much feedback as possible before starting the development work. While waiting for feedback, I’m soliciting coding strategies from Brady and Rod. I will also open up a review site for you and others to play with shortly.
bradymiller wrote on Monday, December 21, 2009:
hey,
Here would be my quick stab at the sql tables (note I’m a relative novice at sql; just trying to give a general idea of my thinking)(I also don’t have a clear grasp on the NULL vs ’ ’ use)(I’m also guessing on the use of the keys):
<pre><code>
DROP TABLE IF EXISTS `clinical_reminder`;
CREATE TABLE `clinical_reminder` (
`id` bigint(20) NOT NULL auto_increment,
`active` tinyint(4) NOT NULL default ‘1’,
`category` varchar(255) NOT NULL default ‘’,
`sex_filter` varchar(255) NOT NULL default ‘’,
`code_filter` varchar(255) NOT NULL default ‘’,
`age_low_filter` float(6,2) default ‘0.00’ COMMENT ‘standardize to months’,
`age_high_filter` float(6,2) default ‘0.00’ COMMENT ‘standardize to months’,
`frequency` float(6,2) default ‘0.00’ COMMENT ‘standardize to months’,
`age` float(6,2) default ‘0.00’ ‘standardize to months’,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1 ;
DROP TABLE IF EXISTS `clinical_reminder_map`;
CREATE TABLE `clinical_reminder_map` (
`id_reminder` bigint(20) NOT NULL default ‘0’,
`id_patient` bigint(20) NOT NULL default ‘0’,
`date` date default NULL,
`result` varchar(255) NOT NULL default ‘’,
PRIMARY KEY (`id_reminder`,`id_patient`)
) ENGINE=MyISAM;
</code></pre>
This should allow all the functionality I discussed in my first message #2 above. Also note I’ve added a ‘age’ column in the clinical_reminder; so can store either frequency (ie. every 12 month mammogram) or can store an age (ie. immunizations for 6 month old baby). Very curious to hear what Rod thinks of this.
-brady
sunsetsystems wrote on Monday, December 21, 2009:
Just a quick initial question/comment - would the “Messages Box” be using Patient Notes? Keep in mind that these already constitute an interoffice messaging system, and it would seem very messy to have two of them.
bradymiller wrote on Monday, December 21, 2009:
hey,
Some more thoughts here:
I’d also add the following columns to the ‘clinical_reminder’ table:
- ‘sub\_category’ (allow more granularity in organizing and in selecting rule sets for patients)
- ‘title’ (what is seen in the final clinical reminder screen if rule is applicable)
- ‘link’ (where the link goes to if click on the title in the clinical reminder screen; usually will go to a default screen, but in some cases may want a custom screen. ie. smoking)
- ‘map\_filter’ (for mapping specific OpenEMR database fields to the reminder engine. ie. smoking status. more on this below)
<br>
My initial thought was that the ‘code\_filter’ could be used to automatically detect patients with certain dx (such as diabetes) in their problem list, however this isn’t that simple. For example, do we use terms, ICD-9, ICD-10, or SNOMED-CT codes; really another project to overhaul the problem lists to get this feature. So, instead, could have a clinical reminder screen per patient, where doc selects what catgeories and sub-categories to put specific patient in (by default, all generic rules would be selected (preventative health,immunizations, smoking, etc.) except the diagnostic ones (diabetes, asthma, etc.) would need to be selected).(this would require one or two more database columns in patient_data to store this).
To further expand on the ‘map\_filter’ suggestion above, using smoking status as an example. Could use formatting such as tableName::columnName::data there, and if it matches then the rule is activated. For example:
- history\_data::tobacco\_current::‘YES’ could activate a rule on what to do with smokers. (could set yearly frequency to suggest quitting)
- history\_data::tobacco\_current::’’ could activate a rule if it is unknown whether the patient is currently smoking. (could suggest to inquire if the patient smokes)
<br>
What I like about this structure so far is that it also will innately support internationalization
-brady
bradymiller wrote on Tuesday, December 22, 2009:
hey,
Realized that my mechanism doesn’t clearly support disrcete data (would be separate data storage of a flu shot for people over age 60 and patients with diabetes). So, probably best to migrate the ‘category’ and ‘subcategory’ columns out of the table and place these in another mapping table, call it ‘reminder\_categories’. Then each rule, such as Flu shot can be placed in multiple categories and ensure the the data is stored in the same place in the ‘clinical\_reminder\_map’ table.
Also, in ‘clinical\_reminder’ table seems better to place all the ‘filter’ columns into one ‘rules’ column to describe all the rules using a logical syntax, such as age > 600 || category == diabetes etc.
-brady
sunsetsystems wrote on Tuesday, December 22, 2009:
Certainly there are many approaches. I’ll throw out a couple of thoughts.
Reminder categories could be done similarly to document categories, where there is one table that supports an arbitrary number of levels. See the table “categories” and in particular the use of its “parent” column.
Regarding a diagnosis filter, there is already a precedent in OpenEMR for linking codes (the “codes” table) with a table column, and includes the code type, not necessarily just ICD9. See interface/patient\_file/encounter/find\_code\_popup.php, and search for places that invoke it. This supports multiple codes, but not an arbitrarily large number.
It may be useful if the reminder ID is a short descriptive name (text). This might support a “plug-in” system for custom screens, for example if the reminder ID matches a name in some directory, then that is taken to be a script that is invoked to drive the custom form.
Finally, I’d just stay start with something fairly simple. There’s nothing like seeing a new feature working to generate ideas for making it better.
bradymiller wrote on Tuesday, December 22, 2009:
To clarify, here’s where I am at so far in data structure (put flu shot and smoking cessation as examples) The ‘titles’ of all the id strings can be managed via the lists:
<pre><code>
clinical_reminder {
name (‘flu shot’) (‘smoking cessation’)
active (‘1’) (‘1’)
rules (’(age > 60) || (category == disease::diabetes)’)(’(map ==history_patient::smoking_current::YES)’)
frequency (‘12’)(‘12’)
age (’’)(’’)
link (lcoation to default popup)(location to smoking cessation popup)
}
reminder_categories {
category (‘disease’)(‘preventative health’)
sub_category (‘diabetes’)(‘smoking’)
name_reminder (‘flu shot’)(‘smoking cessation’)
}
clinical_reminder_map {
name_reminder (‘flu shot’)(‘smoking cessation’)
id_patient (id from patient_data table)(id from patient_data table)
date (timestamp here) (timestamp here)
result (’’)(‘told patient to quit, he laughed at me’)
}
</code></pre>
-brady
anonymous wrote on Tuesday, December 22, 2009:
Hi Rod,
Would you recommend that we expand the code structure of Patient Notes so that it can be used for both Messages and Patient Notes?
* Patient Notes (Existing features)
* System to Provider (Good for health maintenance/disease management)
* Provider to Provider (Useful for in-clinic administration)
The System to Provider feature is useful for tracking and monitoring plan actions for health maintenance/disease management.
The Provider to Provider feature is useful for medicine and lab administration. For example, a physician can order a flu shot in the exam room and route it to a support staff for administration. Another example, a nurse can order a refill during a nurse visit and route it to the physician for approval.
sunsetsystems wrote on Tuesday, December 22, 2009:
Thomas, provider-to-provider routing is already integrated into Patient Notes. This is why I referenced it as an existing interoffice messaging system. It is very reasonable to also add code where appropriate to have the system generate these notes. I have done work recently with Patient Notes so it is especially important to make sure you are working with the latest CVS if you get into this code.
My main point is, please just one messaging system!
anonymous wrote on Tuesday, December 22, 2009:
Hi Rod,
I agree with one system, and thus the need to expand the code structure. Currently, the Provide-to-Provider feature is patient centric and is hidden in individual patient’s Medical Record. The proposed solution is to have a Messages box that is provider centric. This would be much easier for a provider to manage different types of messages.
The latest CVS has been applied yesterday.
sunsetsystems wrote on Tuesday, December 22, 2009:
Yes, Patient Notes are currently always within the context of a patient and are meant to be retained as part of the patient’s medical record (not “hidden” any more than other medical records are).
Is there a need for general-purpose messaging that does not concern patients? If so I guess support could be added for a type of note where pnotes.pid = 0. Or else send email. I wouldn’t want to re-invent email in OpenEMR.
anonymous wrote on Tuesday, December 22, 2009:
I think the key is about ease of patient management. It’s much easier for providers and administrative staff to manage patient activities in one location. It’s very time consuming to do it patient by patient. This is what I have seen in all four of the EHR systems I have worked with.
There are many applications for a Messages box. For example, the system can send a reminder message to a provider if a patient encounter is not closed within a certain period of time. This helps to ensure that an encounter is properly documented and billing taken care of.
When we work with Lab, the PCP can also be notified when Quest or Labcorp send results through the interface. Otherwise, the provider would need to check each patient record daily just to see if there is any lab result.
Last but not least, I think there is some implication from HIIPA perspective. For example, if the physician wants the front desk to set up a followup appointment for a patient. There is no need for the front desk clerk to access a patient’s medical record. S/he can get the info from the Messages box.
anonymous wrote on Tuesday, December 22, 2009:
Here’s a quick link to HIPAA Privacy Rule:
What I’m referring to is “Limiting Uses and Disclosures to the Minimum Necessary.” I’m no expect on HIPPA…this is more about my experience with several organizations I have worked with.
: http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html
bradymiller wrote on Tuesday, December 22, 2009:
hey,
More thoughts on this. I’m gonna break this project down into elements in order of priority that I think need to be completed:
1) Underlying database structure that holds the rules
2) Algorithm that “decides” which rules that are in the database apply to a specific patient.
3) Management/adding/removing/organizing rules in the database structure
4) Creating the output display and the reminders using the algorithm in number 2. (in my mind, this item (#4) will take far less time than #1-3)
A lot has been discussed on #4, but was wondering what your thoughts are on #1-3 . This is a good scenario for you Thomas, because #1-3 don’t really require much OpenEMR knowledge. Very interested where you guys are going with it.
-brady
anonymous wrote on Tuesday, December 22, 2009:
Hi Brady,
My team is following your recommendation, studying the codes, and waiting for more feedback. This piece is tied with other MUs, so we are taking them into consideration. I will let you know as soon as we have some coding done.