CCHIT - Medication Reconciliation

anonymous wrote on Saturday, January 30, 2010:

This MU is interesting because OpenEMR seems to be using a combined Rx order entry and medication list. However, some features are missing, and our proposal is to modify the Rx section to meet both the MU and legal requirements.

There is also another team developing e-prescribing order entry, which can be integrated with the manual order entry. I will ask them review this MU as well.

See http://www.openmedsoftware.org/wiki/Medication_Reconciliation for details.

What do you think?

tmccormi wrote on Wednesday, July 28, 2010:

https://sourceforge.net/tracker/?func=detail&aid=3023178&group_id=60081&atid=1245239

Posted To git@github.com:tmccormi/openemr.git
*       mu-22-drugrecon-v3 -> mu-22-drugrecon-v3
tony@backporch:/opt/workspace/git4dev/openemr$ git log
commit eb4b497264827d97ec0c78efda1adfb534d1179c
Author: tmccormi <tony@mi-squared.com>
Date:   Tue Jul 27 22:14:44 2010 -0700

    Fix the case of the word current

commit 3ae3c7ae7f43bcae24620186402907901fc94d2e
Author: tmccormi <tony@mi-squared.com>
Date:   Tue Jul 27 18:17:36 2010 -0700

    EMR Tech Drug Reconciliation code

-Tony on behalf of EMR Tech, Fei and Verbus

bradymiller wrote on Saturday, July 31, 2010:

Tony,

I’ve placed some coding issues on github. My main concern though is the testing; I’m really unclear what this module is supposed to accomplish. Several issues:
1) Mucking up the issue summary page with the Reconcile Status/Date columns and the actual edit entries with the reconcilation forms on all issues (not just the medications)
2) Then creating an awkward patient note and throwing the entry in the log
3) What exactly is being reconciled here? Generally in a clinic flow a reconcilation involves looking at list(s) of meds, and checking which ones the patient is currently taking. I am not really getting this from the current implementation.
4) Pnotes doesn’t seem to be the appropriate mechanism here. Why not consider making another table to store the reconcile status/note/date and then connect it to the med issue and/or prescription via the functions in the openemr/library/gprelations.inc.php script (gprelations table). Then you’d automatically store records of all reconciliations, and could base a gui on this that actually allows practitioner to reconcile meds/prescriptions on one screen without mucking up the other gui’s.

-brady

tmccormi wrote on Monday, August 02, 2010:

* rant warning *

The design was posted on the wiki many, many months ago, would have been nice to get some feed back before the volunteers spent time implementing it just to have the whole thing rejected.    It’s not going to make them very receptive to future work.

The design of the issues/list table is terrible and they did their best stuff the recon into it along with all the other crud.

I would have preferred to toss the whole thing and have separate tables for each kind of medical issue, then we could do a good job, instead of a hack job all the time.   But that would be yet another big design that no one would look at until afterwards.

The reason the recon dates/info is on the issue summary page is so you can use it like you described - to see the list of meds and the last review date and then update it.

* rant over, thanks for listening *

That said, Sam Bowen had similar feed back and, frankly I agree with you both, I’m not a doctor and I don’t do these activities myself, so I suggest some that someone that knows the specific use case post a new design proposal on the wiki and, hopefully, someone will be willing to do it.  Screen mock ups are important for the volunteers to use to get a very clean idea of what you have in mind.

What has be submitted may not be optimal, but it will pass MU cert criteria, all that is required is a way to do it and log what you did.  I, personally, thought it was important to put that fact that the drugs had been reviewed in the patient note where they could be part of the medical history, not just a audit log item, but perhaps I was wrong.

-Tony

bradymiller wrote on Monday, August 02, 2010:

Tony,

Let the volunteers know the code is solid within the OpenEMR framework; in all honesty, this is something for them to be proud of considering the difficulty some other groups have had. Just because it may end up in the OpenEMR graveyard doesn’t mean it was time wasted; those coders now know the basics to code in OpenEMR.

No point in creating confusing noise(specifically mucking up the pnotes and issues gui) along with a rather meaningless feature to get a MU item done. The hope is that completion of the MU items would actually improve OpenEMR, correct?

I’d suggest considering the strategy I discussed above. The cool thing here is you can use the gp relations table to attach the issues and prescriptions to item(s) in the reconcile table. This would then be straightforward to create a gui screen that allows user to reconcile both lists(s). This list of reconciled meds could then be the active medication list. So , in one swipe could get MU and bring together the prescription/medIssues into a true active medication list. This mechanism could then be built on in the future to fix your issues with the medication entries in the issues/list tables along with adding active/inactive/refill/etc. functionalities.

-brady

mike-h30 wrote on Monday, August 02, 2010:

I also agree that each prescription written for a patient should have a table entry for complete prescription tracking storing the date and dosage of each medication prescribed.  We had a random visit by the DEA a few months ago and the agent pointed out that our current system was not acceptable for tracking narcotics and Suboxone prescriptions.  The agent asked to see a history of random patients for each date a narcotic was prescribed.  Our previous EMR ( Amazing Charts)  recorded every date and dosage for each medication that was prescribed.  It would be nice to have that functionality added in future versions of OpenEMR.

drbowen wrote on Monday, August 02, 2010:

We use the current “lists” exclusively to monitor store and record all of our active medications.    At some point when the e-prescription that is tightly integrated comes on line with OpenEMR will will need a better correlation of the medication “lists” and the “Prescriptions.”

If I understand what Brady is proposing, it does sound like a cleaner solution.

It would help if ALL the developers would at least look at the wiki periodically so that they can be aware of what is being proposed.  There have been multiple instances where development work was proposed, you were asked to comment, and we got no response.  Then when the work was delivered we got several public and painful written lashings.  If we ask for comment and get no response,  we have to assume that there is no objection.  It is unfair to treat volunteer developers in this fashion.

Brady, you have become a very critical member of our quality control team and we could definitely use your eyes on these documents before the work gets very advanced.

Sam Bowen, MD
http://oemr.org

bradymiller wrote on Tuesday, August 03, 2010:

Sam,

The above was not a lashing, just a code review. I generally save the lashings for Tony’s sql upgrade script code commits… He’s thick skinned and he’s a pro, so that doesn’t really count :slight_smile:

The med listing/prescriptions is a complicated issue in OpenEMR, and it’s really difficulty to predict the success of something until that first set of code is reviewed. Mock up screens and overall strategy just aren’t enough for me; I need some code. For example, I only became aware of the gprelations table in the last week, while coding this:
http://github.com/openemr/openemr/commit/21e15cce4507d36c7ffd234f2c4f034b38d1087e
So, only reason this mechanism became apparent is because I was reviewing that code while working on my code; the way of open source collaboration.

Volunteer developers are treated fairly and provided with tools and unlimited support; I along with others consider these developers (I myself am a volunteer) to be vital to the future success of OpenEMR. But in any project, coding may not get to the official codebase. Even if this code does not get to the codebase, as I brought up above, these developers have learned important skills of OpenEMR development, and are one step closer to finishing this MU requirement.

-brady

drbowen wrote on Tuesday, August 03, 2010:

Tony is tough and can take it.

Most of these modules have been generated by more junior developers and passed on to Tony for review.  They feel the lash even though it is directed at Tony.

Sam Bowen
http://oemr.org

bradymiller wrote on Tuesday, August 03, 2010:

Sam,
“Most of these modules have been generated by more junior developers and passed on to Tony for review.” How many patches have gone this route, like two??

Tony, would probably be better to request the volunteers to post their code directly via the tracker or github; no reason being the middleman. Collaboration is easier when in direct communication.  It is still very helpful to get your code review though, since we really need to get more reviewers in the mix with the recent increase of code submissions.

-brady

mmfsystems wrote on Thursday, February 17, 2011:

HI All,

I want to merge Medication Reconciliation MU in my emr application. As per its explanation and ongoing discussion regarding it ,I have following questions for below mentioned points:

     a) The system shall allow the provider to Electronically complete medication reconciliation of two or more medication
          lists (compare and merge) into a single  medication list that can be electronically displayed in real-time.
         
         Question: As it is mentioned in MU requirements that “THIS point may not be needed as we only have one medication
                           list *** I’ll add this to the issues list for   tonights MU Project meeting” ,my question is whether
                          reconciliation(comparing and merging) code is under process or it is not needed anymore ?

     b) For each record, add a new status: current, canceled, discontinued. “We cannot delete a medication record”. So we
         need a “canceled” status for any input mistake, e.g. wrong name or a duplicate. Discontinued is used when the
         patient is no longer taking the medication.

       Question: It is mentioned in point (b) that we cannot “delete a medication record” my question is in OpenEmr4.0
                         medication deletion option is there in add_edit_issue.php page itself, so why canceled status has
                         been  given?

   c) Files that has been mentioned for medication reconciliation are as follows:
          1) interface/patient_file/summary/add_edit_issue.php b/interface/patient_file/summary/add_edit_issue.php
          2) interface/patient_file/summary/stats_full.php b/interface/patient_file/summary/stats_full.php
          3) interface/reports/prescriptions_report.php b/interface/reports/prescriptions_report.php
          4) library/globals.inc.php b/library/globals.inc.php
          5) sql/3_2_0-to-4_0_0_upgrade.sql
          6) sql/database.sql b/sql/database.sql

   Question:Is there any changes made to prescriptions_report.php as I am unable to find changes regarding it in the patch
                    available?

   Please clarify.

Thanks & Regards
MMF Systems

bradymiller wrote on Saturday, February 19, 2011:

hi,
Any outcome on whether we even need a Medication Reconciliation?
-brady