Vitals in e-prescriptions
The SCRIPT standard allows transmission of vital signs (height, weight, blood pressure). Pharmacists should be aware.
On November 27, 2019, I posted the following article to my LinkedIn page. I wanted to repost it here on my newsletter for context for a future article discussing more recent developments with how this data is transmitted. That article will discuss LOINC coding of these vital signs and its implications, as well as allergy data contained in these transmissions. As an editorial comment: since I wrote this article, my software vendor, PioneerRx, has created a function which extracts these data points and codifies them into the patient chart for easy trend review and inclusion with eCare Plans. That was an excellent move.
Anyhow, what follows is the original article published on LinkedIn in 2019:
About 6 months ago, while checking a prescription at the pharmacy, the output image of the prescription was not displaying (this happens from time to time when I haven't closed out of our pharmacy software in over a week, closing and re-opening the program usually fixes it). So I decided to check the prescription by just reviewing the raw xml transmission. As I was doing so, I noticed something odd: This prescription had multiple fields I had never seen before! It contained an "observations" field with a patient height, weight and blood pressure. It also contained a "benefits coordination" field with insurance information for the patient. That is useful information. I thought about doing something with it, but didn't until I noticed this again about 1 month ago for the same reason.
So I called my software company (PioneerRx) and modified the output image to display the height, weight and blood pressure when they are transmitted with the prescription. Over the next two weeks, as a result of this change, I noticed a LOT more prescriptions were sending with this information than I expected. Two prescriptions in particular stick out in my mind: one a new prescription for an antihypertensive in which the blood pressure was over 160/90 mmHg, which made me decide to spend a little more time counseling this patient than I normally would have. (I'm sure my employer is thrilled about this, as we got reimbursed all of about $4 for that prescription - can't afford to pay an expensive pharmacist to counsel for 15 minutes on that reimbursement!).
The second prescription was for an antidepressant. A review of the patient's profile revealed that a) they were not on any blood pressure therapy, and b) this was the first blood pressure reading recorded on any prescription, at 155/93. I put a note to counsel the patient at pickup, and to take a blood pressure at that time. Unfortunately, the patient picked up through our drive through and was in a hurry, but promised to talk more about it upon refill. I'm ok with that. Hypertension is a 10-year problem, not a 1 hour problem.
After these two experiences, I decided to look at this data more globally. This week, I completed two reviews of the blood pressure information that is sending over with e-prescriptions. Here are my findings:
1) In my data, over the past week, 20% of e-prescriptions contain a BP.
2) All of these BPs are coming from two health systems (but oddly not every clinic in these systems), both of which use Epic (specifically EpicCare version February 2019).
3) One of the health systems (University of Utah Health) has transitioned to SCRIPT 2017071. The other, St. Mark's Hospital (apparently a subsidiary of HCA), has not transitioned to the new SCRIPT standard. This suggests that BP transmission is unrelated to SCRIPT standard implementation.
4) According to the independent pharmacy helpline at SureScripts, height and weight will be required on ALL prescriptions for children with the new SCRIPT standard (for which the CMS mandate goes into effect 1/1/2020). BP and height/weight for adults are optional fields.
5) A closer look at prescriptions written by U of U health physicians (filtered by looking at prescriber phone number prefix 801-581-xxxx) shows that 109 out of 207 e-prescriptions processed in the past month contained a blood pressure.
6) Of the 109 prescriptions containing a BP, 40 were uncontrolled at above 130/80 based on the 2017 AHA/ACC guidelines. These 40 prescriptions were for 22 unique patients.
7) I put a "Care Goal" in Pioneer to follow up on these 22 patients at their next pickup. I also plan to document and transmit a Pharmacist's e-Care plan to CPESN USA when I do follow up (because if it isn't documented it didn't happen!)
8) Of the 22 patients, about half are currently on antihypertensive therapy, and the other half are not, based on our records.
9) Another 20 or so BPs were associated with antihypertensive prescriptions, but were controlled, suggesting that the current therapy is effective.
10) Of the 98 prescriptions I reviewed that DIDN'T contain a BP, I came up with the following reasons: RefillResponse transactions don't seem to transmit this data. A few prescriptions were e-prescriptions that failed to transmit and were therefore converted to a fax. A few prescriptions had a height or weight, but no blood pressure, suggesting that there wasn't a blood pressure in the patient chart, or there was a coding issue on the send side. The rest of the prescriptions seemed to come from certain clinics that perhaps haven't shifted to the latest build of their system-wide EHR, or were false positive affiliations (after all I did a phone number search to generate this list of prescriptions).
Wish me luck in following through with these 22 patients, and in building a reimbursement model for this type of follow up in the community pharmacy setting. The PBM-set drug reimbursement for the lisinopril and amlodipine at $4-10 per prescriptions isn't really going to pay for the type of hypertension service I'm envisioning as I consider these results. I'd love to work with an employer or insurer to work out a payment methodology for this type of work.
I'm also excited to share this information so that other pharmacies can build on what I'm doing. Also I'd love to figure out how to work with health systems and EHR vendors to ensure this data gets transmitted with a lot more than 20% of prescriptions.
I figure to make this data usable for all community pharmacists, we have the following prerequisites. 1) pharmacy software vendors need to ensure this information gets into their database in a usable format, so that it can be displayed with prescriptions. 2) pharmacies need to choose to display this information. 3) there needs to be a business case for pharmacies to choose to spend pharmacist time evaluating and acting on this information. This requires a new payment model for pharmacies outside of the MAC/GER/DIR/AWP/DFER alphabet soup that is the current PBM-controlled reimbursement system. 4) EHR vendors and builders at each health system need to be able to transmit this data and need to choose to share it. 5) Payers/purchasers, patients and physicians need to see community pharmacies as more than a retailer.
Community pharmacists are clinically trained, especially in chronic disease therapeutics, have access to a wealth of health information and see patients with chronic diseases far more often than their physician does. There needs to be a better way to pay us for services outside of dispensing, because the current PBM-dominated model seems to lead to one outcome: minimally staffed corporate-owned pharmacies focused on getting pills out the door as fast as possible regardless of the appropriateness of the therapy. Please join me in this adventure to change the way that pharmacies work and get paid from moving pills out as fast as possible to ensuring that patients have optimal outcomes from their drug therapy.