bradymiller wrote on Wednesday, December 30, 2015:
If coding is needed, then won't be ready to address a8 issues by 12/31 slot. Sounds like labs won't be ready either. My thoughts though are that all can be accomplished with configuration(read below).
At this point, I think I have the testing criteria for a8 memorized, and some of the testers input seems way out of scope.
To address all of the tester's concerns:
My first section below contains the logic flaws by the tester, which I think needs to be addressed at a higher level(ie. perhaps Tony with the testing folks):
1. The first thing that is very odd is the attempted definition of a "trigger". CDR rules are not that simple. It's best to think in terms of a rule being "based" on certain elements in the database. For example, the Hypertension rule uses the following:
a. Is Hypertension a medical problem for the patient?
b. Is a blood pressure recorded for the patient?
To attempt to classify one element as the trigger is arbitrary. The fact that this rule is using a vital sign element in the database to reach a decision means it is using a vital sign element; to me this concept seems really simply.
As a quick mental exercise, then what would be the "trigger" if we changed the Hypertension rule to just use the following:
a. Is a blood pressure recorded for the patient?
In fact, the certification even requires a rule that test a combination of two different categories. If that is the case, then again, they can't both be "triggers" according to the testers current flawed logic. For example, the rule that does that in OpenEMR is the Coumadin INR rule, which uses the following:
a. Is the patient on coumadin? (checks a medication element)
b. Does the patient not have an INR lab within the last 4 months? (checks a lab element)
If we were to follow the testers flawed logic, then we can make the "lab" the trigger, by instead doing only the following:
a. Does the patient not have an INR lab within the last 4 months? (checks a lab element)
(it would be a less meaningful rule, but now the lab is the supposed "trigger")
2.The second logic flaw is forcing allergy/drug and drug/drug interaction section by native OpenEMR when Newcrop does this already and Newcrop is required for MU2. I am simply at a loss of words on this one... Note the wording of these test in the testing guide use the following phrase "Using the Vendor-identified EHR function(s),"... Meaning we get to choose what to use...
3.In the testing book criteria for item a8, there is an explicit note to the tester that the structure of the intervention is not explicitly defined. Meaning the actual workflow/process is up to us. Here is the quote from the testing guide for this issue:
"The following points have been added as clarification for the Tester:"
"The structure of a clinical decision support intervention is not explicitly defined. The Vendor may
choose to define an intervention in a variety of ways, including, but not limited to: automated
workflow modifications, prompting or facilitation of clinical documentation (e.g., condition-specific
flowsheets, highlighting or making available additional structured documentation based upon
triggers, data-driven care plans and documentation templates, CDS rules engine, hard-coded
interventions), suggested orders/order sets, or user-facing messages, reminders, or warnings"
I can guarantee you that this clarfication was added for a good reason...
This means that all of the details of using active/passive and where to place reminders is not up to the testers; it is up to us... Again, the tester is going way out of scope on these types of issues.
For example, for the vital sign rules, they don't need to be encapsulated within the Clinical reminder widget; just highlighting an abnormal vital signs when showing the vitals would even suffice; this is the same for the labs; this is the same for allergies. As long as there is something that makes some sort of decision regarding the data element, it is fair game. And it can be ugly, pretty, awkward, or even make farting noises(as long as they occur automatically and electronically); it is up to us
Now on to how to fix issues(which I think are all just configuration issues):
The abnormal lab highlighting: didn't we solve this issue already by using the Procedures->Lab Overview gui?
For the fine grained CLINICAL rule, this can done by configuration, which I already showed how to do for the Hypertension rule in a post above.
For the CCDA, I emailed you a CCDA that has following elements to activate rules:
a. HTN medical problem (activates check blood pressure alert)
b. Penicillin prescription (activates allergy/med alert)
c. Penicillin allergy (activates allergy/med alert and activates the penicillin allergy rule; note the penicillin allergy rule needs to be turned on in Administration->Alerts)
So that is 3 rules using the 3 elements.
For the allergy issue, placing it in the Clinical Reminder section would be really awkward, and as discussed above is up to us where to place(Do note the allergy does show up in the Active Alert popup along with the active reminders, which is the testers preferred mechanism anyways). For the online link to information, then we can take advantage of the "Patient-specific education resources" stuff added by Rod. If you go to the Patient Summary->Issues page, you will see the column 'Coding (click for education)'. If there is a code there associated with the allergy, then if you click on it, you will be directed to a choice of viewing information via Medline or via local information.
Keep up the perseverence,