Final MU Objectives: Drug Contraindication, Problem Lists, e-Prescribing
This is the second in a series of hospital-focused summaries of the final Stage 1 meaningful use objectives and measures. The goal of these entries is to support rural community hospital personnel in their efforts to meet specific meaningful use objectives. Notations marked “implications…” are my interpretations, which may or may not be correct.
Objective #1, CPOE, was covered in a previous blog: http://www.worh.org/hit/2010/07/final-stage-1-meaningful-use-objectives-overview-and-analysis-of-cpoe/
Objective #2: Implement drug-drug and drug-allergy checks (Core Set)
The main difference between the proposed and final drug contraindication objectives is that the drug formulary check has been separated from the drug-drug drug-allergy check. The drug-drug drug-allergy check has been designated as a core set objective (required), and the drug-formulary check has been designated as a menu set objective (must pick 5 out of a menu of 10).
The proposed drug-contraindication objective for EPs and hospitals was: “Implement drug-drug, drug-allergy, and drug-formulary checks.”
The final drug-drug drug-allergy check objective is: “Implement drug-drug and drug-allergy checks.”
The objective must be achieved using certified EHR technology as defined in the final certification rule. The definition of drug-drug and drug-allergy check functionality in the final certification rule is: (1) “Automatically and electronically generate and indicate in real-time, notifications at the point of care for drug-drug and drug-allergy contraindications based on medication list, medication allergy list, and computerized provider order entry (CPOE)” and (2) “Provide certain users with the ability to adjust notifications provided for drug-drug and drug-allergy interaction checks.”
Implications of the above: Community hospital information systems (HIS) generally have distinctive pharmacy and provider ordering modules, both modules with contraindication check capabilities that can be adjusted by severity level. Since the certified product must generate notifications at the point of care, and must be “based on CPOE,” it is reasonable to assume that this objective is referring to the contraindication functionality of the provider ordering module.
The proposed drug-contraindication measure for EPs and hospitals was: “The EP/eligible hospital/CAH has enabled the drug-drug, drug-allergy, drug-formulary check functionality.”
The final drug-drug drug-allergy check measure is: “The EP/eligible hospital/CAH has enabled drug-drug and drug-allergy check functionality for the entire EHR reporting period.”
The ability to calculate the measure will be included in the certified EHR technology as a certification requirement.
Exclusion: If an EP writes fewer than one hundred prescriptions during the EHR reporting period they would be excluded from this requirement. There is no exclusion for hospitals
This measure requires a Yes/No attestation indicating that the required functionality has been enabled for the entire reporting period.
Objective #3: Implement drug-formulary checks (Menu Set)
The main difference between the proposed and final drug contraindication objectives is that the drug formulary check has been separated from the drug-drug/allergy check. The drug-drug/ allergy check has been designated as a core set objective (required), and the drug-formulary check has been designated as a menu set objective (must pick 5 out of a menu of 10).
The proposed drug-contraindication objective for EPs and hospitals was: “Implement drug-drug, drug-allergy, and drug-formulary checks.”
The final drug-formulary check objective is: “Implement drug-formulary checks.”
The objective must be achieved using certified EHR technology as defined in the final certification rule. The definition of drug-formulary check functionality in the final certification rule is: “Enable a user to electronically check if drugs are in a formulary or preferred drug list.”
Implications of the above: Community hospital information systems (HIS) generally have pharmacy applications with internal formularies that can be queried from provider ordering and other modules. It seems reasonable that the utilization of such an internal formulary would be sufficient to meet the objective.
The proposed drug-contraindication measure for EPs and hospitals was: “The EP/eligible hospital/CAH has enabled the drug-drug, drug-allergy, drug-formulary check functionality.”
The final drug-allergy check measure is: “The EP/eligible hospital/CAH has enabled drug-formulary check functionality and has access to at least one internal or external formulary for the entire EHR reporting period.”
The ability to calculate the measure will be included in the certified EHR technology as a certification requirement.
Exclusion: If an EP writes fewer than one hundred prescriptions during the EHR reporting period they would be excluded from this requirement. There is no exclusion for hospitals.
This measure requires a Yes/No attestation indicating that the required functionality has been enabled for the entire reporting period.
Hint regarding possible future stage adjustment: “The formularies should be relevant for patient care during the prescribing process. To further address this, we expect that this measure will be expanded to be counted on a transactional basis for future stages.”
Objective #4: Maintain an up-to-date problem list (Core Set)
The proposed problem list objective for EPs and hospitals was: “Maintain an up-to-date problem list of current and active diagnoses based on ICD-9-CM-CM or SNOMED CT.”
The final problem list objective is: “Maintain an up-to-date problem list of current and active diagnoses.”
CMS supporting language: “We did not and do not intend that coding of the diagnosis be done at the point of care. This coding could be done later and by individuals other than the diagnosing provider.”
The objective must be achieved using certified EHR technology as defined in the final certification rule. The definition of problem list functionality in the final certification rule is: “Enable a user to electronically record, modify, and retrieve a patient’s problem list for longitudinal care.”
ONC supporting language: “The reference to longitudinal care is intended to convey that the problem list must be comprehensive in the sense that it must be capable of including entries provided over an extended period of time. Consequently, for Complete EHRs and EHR Modules to be certified for an ambulatory setting, they will need to be designed to enable the user to electronically record, modify, and retrieve a patient’s problem list over multiple encounters. For an inpatient setting, they will need to enable the user to electronically record, modify, and retrieve a patient’s problem list for the duration of an entire hospitalization.”
Implications of the above: Community hospital information systems generally have distinctive problem list functions in their HIM (medical records) and patient care documentation modules. Due to the need for coding after the care encounter, the patient care documentation problem list modules are often underutilized. Given the focus on longitudinal care and the implicit final rule expectation that the problem lists will be available for viewing and modification (if not coding) at the point of care, providers that are not already doing so should expect to be required to begin utilizing their patient care documentation module problem lists. Vendor capability to “pull forward” the problem list for reviewing and modification through multiple encounters or care transitions may also be an issue.
The proposed problem list measure for EPs and hospitals was: “At least 80% of unique patients seen by the EP or admitted to the eligible hospital or CAH have at least one entry or an indication of none recorded as structured data.”
The final problem list measure is: “More than 80% of all unique patients seen by the EP or admitted to the eligible hospital’s or CAH’s inpatient or emergency departments (POS 21 or 23) have at least one entry or an indication that no problems are known for the patient recorded as structured data.
“Unique patient” means that if the patient is seen more than once during the reporting period, he or she only counts once in the denominator, which means that the objective has been met if the problem list is maintained during at least one of the patient encounters.
The ability to calculate the measure will be included in the certified EHR technology as a certification requirement.
The Denominator is: “Number of unique patients seen by the EP or admitted to an eligible hospital’s or CAH’s inpatient or emergency department (POS 21 or 23) during the EHR reporting period.”
The Numerator is: “The number of patients in the denominator who have at least one entry or an indication that no problems are known for the patient recorded as structured data in their problem list.”
The Threshold is: “The resulting percentage must be more than 80% in order for an EP, eligible hospital, or CAH to meet this measure.”
Exclusion: There are no exclusions.
Objective #5: E-prescribing (Core Set: for EPs only)
The proposed e-prescribing objective (for EPs only) was: “Generate and transmit permissible prescriptions electronically (eRx).”
The final e-prescribing objective is: No change: finalized as proposed.
The objective must be achieved using certified EHR technology as defined in the final certification rule. The definition of e-prescribing functionality in the final certification rule is: “Electronic prescribing. Enable a user to electronically generate and transmit prescriptions and prescription-related information in accordance with: (1) The standard specified in §170.205(b)(1) or §170.205(b)(2); and (2) The standard specified in 170.207(d).”
ONC supporting language on standards: “We are … revising the standard to state: “Any source vocabulary that is included in RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine.” We note that in section 3.1, of the most recent release of the “RxNorm Documentation (06/07/10, Version 2010-3)7,” NLM has identified the following source vocabularies as being included in RxNorm: (1) GS – Gold Standard Alchemy, (2) MDDB – Medi-Span Master Drug Data Base, (3) MMSL – Multum MediSource Lexicon, (4) MMX – Micromedex DRUGDEX, (5) MSH – Medical Subject Headings (MeSH). (6) MTHFDA – FDA National Drug Code Directory, (7) MTHSPL – FDA Structured Product Labels, (8) NDDF – First DataBank NDDF Plus Source Vocabulary, (9) NDFRT – Veterans Health Administration National Drug File – Reference Terminology, (10) SNOMED CT – SNOMED Clinical Terms (drug information), (11) VANDF – Veterans Health Administration National Drug File. We clarify for commenters that the standard we have adopted is a functional standard that enables the use of any source vocabulary that is included within RxNorm. Consequently, any one of these “source vocabularies” identified by NLM may be used, or any other source vocabulary successfully included within RxNorm.”
The proposed e-prescribing measure for EPs was: “At least 75% of all permissible prescriptions written by the EP are transmitted electronically using certified EHR technology.”
The final e-prescribing measure is: “More than 40% of all permissible prescriptions written by the EP are transmitted electronically using certified EHR technology.”
The ability to calculate the measure will be included in the certified EHR technology as a certification requirement.
The Denominator is: “Number of prescriptions written for drugs requiring a prescription in order to be dispensed other than controlled substances during the EHR reporting period.” (The only patients that are included in the denominator are those patients whose records are maintained using certified EHR technology).
The Numerator is: “The number of prescriptions in the denominator generated and transmitted electronically.”
The Threshold is: “The resulting percentage must be more than 40% in order for an EP to meet this measure.”
Exclusion: “This objective does not apply to any EP who writes fewer that 100 prescriptions during the EHR reporting period.”
More meaningful use objective summaries to come…
{ 4 comments… read them below or add one }
Trying to understand the problem list and how it would be implemented witin the Emergency Room. We currently have an Inpatient problem list implemented. Would we base our ER similar to the IP? I am trying to understand what exactly ” a problem list for ER” would entail. We currently have an “initial assessment form” created.
Could you give me an example of a question from a problem list from ER?
I will try to connect with some ER personnel from hospitals in our cooperative to get you some useful input on this. From an EHR perspective, most inpatient, ambulatory, and ER EHR vendors have a problem list function that allows users to capture past and current medical problems. How you implement would at least partially depend on the vendor’s specific capabilities.
Louis
If the patient’s diagnosis is recorded in a summary, within the EHR, but are not able to be modified within the EHR, does that count as a problem list?
For example, within the Meditech EMR, there is a summary panel that includes the patient’s diagnoses for every visit. These diagnoses are entered by coders, using 3M. With Meditech’s Advanced EMR feature, you can pull a lifetime history on the patient, which will include all diagnoses entered on every visit the patient has had. The problem is that you can only view the diagnosis and ICD9 code.
Thanks in advance,
Loretta
I think different vendors are interpreting how the problem list needs to function differently, but I believe that most have certified their functionality in a way that demonstrates the problems can be updated (not just viewed) by caregivers at the point of care. My advice is to work with your vendor to determine their specific interpretation. You still have the ability to pursue the MU objective outside the vendor’s interpretation (CMS FAQ (10473)), but doing so will expose you to additional risk in case of audit.