CCHIT - Clinical Decision Support

Greetings, here's what we have envisioned regarding the various components of Clinical Decision Support. Please review and share your ideas. Thank you.

http://www.openmedsoftware.org/wiki/Clinical_Decision_Rule

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

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

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

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

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.

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

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.

Rod 
(http://www.sunsetsystems.com/)

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

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

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.

Rod 
(http://www.sunsetsystems.com/)

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

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.

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!

Rod 
(http://www.sunsetsystems.com/)

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.

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.

Rod 
(http://www.sunsetsystems.com/)

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.

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

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

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.

cool.

Just continue to keep us in the loop. This stuff is pretty exciting and will have a relatively large impact on patient care(compared to the other MU's). Also, don't feel inclined to follow my recs; I'm just thinking out loud and am a relative novice in mysql. I'll be especially interested in what your DBA's thoughts are when you start coding.

-brady

Thomas, regarding messages, the "Patient Notes and Authorizations" panel appears on login and also when you select that item (Miscellaneous menu).  It is intended to be the "messages box" that you describe.  Of course I'm sure there are better ways to implement it, and I believe the interface refactoring project is already doing something about that.

Rod 
(http://www.sunsetsystems.com/)

Hi Brady,

Here's the feedback from our DBA based on his initial assessment:

"What Brady suggested is workable. But it has 1 basic limitation:
It will apply for all patients that matches the assigned criteria. If some or any particular patient(s) does not require/allow for the rule, then the structure needs to be there to disable it selectively.

Brady is right in saying that once the structure & algorithm is in place, the popup is easy as it only serves to display the message while the algorithm take cares of the logic.

I think it is complex as the algorithm needs to match up a few criteria:
1. rules
2. plan
3. group assignment
4. patients
5. frequency

I still have no idea how to tide the 5 together. I think this is more on code logic. Once the algorithm is figured out, the database structure can be build to match."

He will work on it some more.

Hi Rod,

I have seen the new GUI as well. It's the same Miscellaneous item. Can I propose to have it renamed to Messages and moved to a high position in the menu tree?

- Calendar
- Messages
- Patient/Client
- Fees
- Administration
- Reports
- Miscellaneous
 
__

The reason is that it will become more important and frequently used as we link it up with decision support, lab, and other MU items.

Yes I think the navigation area will need some rearranging, for various reasons.

Rod 
(http://www.sunsetsystems.com/)