EHR technology should enable a provider to identify patients eligible for education resources specific to their health information as it is logged in the EHR and enable delivery of those resources to the patients.
Medicaid Promoting Interoperability Objective and Calculation
The objective is to use clinically relevant information from Certified EHR Technology to identify patient-specific education resources and provide those resources electronically to the patient.
- Patient-specific education resources identified by Certified EHR Technology are provided electronically to patients for more than 35 percent of all unique patients with office visits seen by the EP during the EHR reporting period.
Denominator for calculation: Number of unique patients seen by the provider in the reporting period
Numerator for calculation: Number of patients in the denominator who are provided patient-specific education resources electronically as indicated by a confirmation status on the Patient Education screen.
- Any EP who has no office visits during the EHR reporting period, or
- An EP that conducts 50 percent or more of his or her patient encounters in a county that does not have 50 percent or more of its housing units with 4Mbps broadband availability according to the latest information available from the FCC on the first day of the EHR reporting period may exclude only the second measure.
Promoting Interoperability Discussion
RevolutionEHR meets certification standards that require the technology to use either the patient’s problem list or medication list to identify the patient-specific education resources. These or additional elements of the EHR can be used in the identification of educational resources that are specific to the patient needs.
New to 2019, however, is the fact that resources need to be provided to the patient electronically. RevolutionEHR makes this possible through the delivery of resources to the patient portal, RevolutionPHR.
A few configuration steps are required for meeting this objective.
1. The user should visit the Encounter set up section of Administration and add the Patient Education screen to the preferred workflow step (it may be best to be set in the Assessment/Plan step, just after the Plan screen, but that decision is ultimately up to the practice) See Example
2. Patient education rules are based on Care Plan Items (CPI) so a good initial step is to consider your rule and build an associated CPI. Let’s use an example where we want to set up a rule that will trigger when we see patients with glaucoma in their problem list. The intent will be for the alert to tell the user that the patient could benefit from a pamphlet related to how to use eye drops. Thus, the CPI will say “How to use eye drops pamphlet provided”. To create the CPI, head to Admin > Data Configuration > Care Plans > Care Plan Item Library > Education: See Example
Selecting “Add Item” in the lower right of screen opens anew window that allows you to first select the “Education Type”. This can be General Info, a Web Site, or a File. For all three options, an “Upload to PHR” checkbox is available and, when checked, will deliver the associated information to the patient’s PHR.
For the sake of this example, let’s create an Education CPI with Type of “File”. The description will be what we’ll see in the encounter workflow so let’s label it “How to use eye drops pamphlet provided”. Then check the “Upload to PHR” box and attach the related file you’d like to actually be delivered to the patient. Ultimately, our CPI looks like this: See Example
3. With the CPI configured to deliver information to the patient’s PHR, we’re now ready to create our Patient Education rule. Head to Admin > System Rules > Patient Education Rules. In this example, we want to create a rule that triggers in the Patient Education screen anytime we see a patient with glaucoma. That doesn’t mean we’re going to deliver the document each time we see a glaucoma patient, but we’d simply like the option to do so for each and every one we see.
There are three steps here: 1) Name the rule, 2) add “Dx Description”, select “Contains” as the operator, and then enter “glaucoma” in the comparison value(s) field, and 3) drag the CPI we created above into the “Search Results” area. (Please note that this is just an example and you can configure your rule in any manner that makes sense to you) Ultimately, our example rule looks like this: See Example
4. With the rule created and the Patient Education screen in our workflow, we’re now in position to use it. When the Patient Education rule triggers on that screen during the encounter, the user must determine if delivery of education is appropriate. If so, the Confirmation Status should be logged as “PHR” in order for the system to post that information to the patient’s PHR account and for the scorecard to log that a patient-specific education item was delivered electronically. (Note that the “PHR” option will NOT be available for a patient who does not have RevolutionPHR credentials) See Example
The associated information is this uploaded to the “About Me” section of the patient’s PHR. See Example
Patient Education Configuration
Patient Education Workflow
Meeting this objective provides moderate challenge given the relatively high threshold of > 35% and interdependency with providing patient access to the patient portal, RevolutionPHR. This will require the user to consider their patient base and the conditions they manage in order to create enough rules for success as well as implement procedures to ensure patients are receiving access to RevolutionPHR.