Category: PIG-let (informatics newbies)

https://www.dropbox.com/s/y2449iiq8xles9m/2023-06%20Info%20Blocking%20Immediate%20Results%20Release%20White%20Paper%20SBAR.pdf?dl=0

The general idea of information sharing between a clinic / hospital / physician/APP and their patients seems like “Mom and Apple Pie”. However, the devil is in the details. How do we approach this at UCHealth?

We do have over 2 decades of discussion on these topics, and these are now distilled for you. I’ve published earlier versions of this document (search info blocking on my blog and you’ll get them).

I was prompted by hospital leadership, as we rebuilt our “physician/APP onboarding” education plan, on how to explain Open Notes and Open Results to our newest providers. I thought of including our latest document from 2020 (wow, that is 6 internet generations ago!), but there were lots of outdated statements.

CMIO’s take? Here you go! My up-to-date version of Information Blocking / Sharing / Open Notes, Open Results introductory document for our newest colleagues at UCHealth; feel free to share amongst yourselves. If you make improvements, please let me know! We’re always looking to improve.

from Bing / Dall-E image generator

Opportunity: Opt out of alerts?

We have a new tool from our EHR vendor to allow physicians/APP’s to “opt out” of future similar interruptive alerts about medications.

For example: “Magnesium in IV for pregnant patient” or
“Ibuprofen interaction with __ drug”

Previously, our physicians/APP’s would either take action (cancel the prescription) or override the alert and state that benefit outweighs risk, EVERY TIME.

Now, our colleagues can FILTER or SUPPRESS these warnings specifically or categorically. As an informatics working group, we have some choices on how to configure this.

Won’t you come along and be a back-seat driver for our conversation?

Q1: Shall we turn this on at all?

I mean, we are doing SUCH A GOOD JOB ALREADY (we are top/worst quartile in “overridden alerts” by our users, among our EHR vendor customers).

A: Yes, we are going to turn this on.

Q2: The pop-up alert allows the prescriber to choose:

Filter for ALL patients or Filter for THIS patient. When we suppress this alert, shall we turn it off FOREVER? Or bring it back every 6 months? Or longer, or shorter? On the one hand, we should respect physician decisions, right? And never show it again? On the other hand, who knows how fast that physician is moving when selecting to “suppress everything — I hate all of you.”

A: Well… after debate, we will leave it at 6 months. Not too burdensome to ask a prescriber twice a year whether they still want this to be filtered. That is 363 days a year we stop asking. And, intermittent re-inforcement is more sustained learning (showing alerts sometimes prompts better retention than every-time alerts that become noise and aggravation).

Q3: What about that choice for THIS patient?

Should the alert be suppressed FOREVER if a prescriber chooses THIS patient? Obviously, the incremental benefit to the prescriber is tiny (I have thousands of patients, so if I choose THIS PATIENT ONLY, I MUST have thought about THIS patient in more detail and we should honor that choice with a FOREVER suppression). For example, “ibuprofen in hypertension” alert. Perhaps THIS patient has tried dozens of other treatments and the ONLY help for migraines is ibuprofen, and yes, I know it affects hypertension, and the risk is worth it. Why remind me again? And, because the benefit is small to the prescriber, the THIS PATIENT setting should be infrequently used, and ONLY with thought.

A: We are investigating if we can make THIS PATIENT suppression setting different from the ALL PATIENT suppression setting.

Q4: What if there are particularly HIGH RISK drug interactions?

Can/should we remove the ability to suppress those interactions? How paternalistic should we be?  EG: Paxlovid and lovastatin: can we allow this to be suppressed?

A: TBD. We are unsure of the granularity of the tools, and we will investigate this further. This will end up being a consensus decision of our committee, backed up by proposing these major decisions to our clinical leaders for approval. It is always a good idea for operational committees like EMO (comprised of practicing clinicians / informaticists / pharmacists / IT analysts / clinical nurse informaticists) to work together to build consensus. Many of these decisions are NOT slam-dunk, as you are starting to see.

Q5:  There is an option to “require a reason” to suppress.

What shall we put there? Should we give several “best guess” reasons, for example:

• Low risk interaction: benefit exceeds risk
• My literature review disagrees with this alert
• Only show this to students and residents. I am an expert
• This is stupid, remove this for everyone (GROSS: Getting Rid of Stupid Stuff)

A: Although the last option is a real project (look it up: GROSS is a clever and memorable acronym invented by other informaticists), this is too many choices. We went with ONE choice “Clinical Judgement – Suppress for 6 months”, because A) No one wants to spend more time on this alert, there will not be much signal here to detect, and B) Suppress for 6 months RESPECTS THE USER by telling them what to expect, and when this will re-appear, to reduce the frustration of “I thought I got rid of this.”

from Bing / Dall-E image generator

Q6: Shall we require a narrative explanation after the choice “Clinical Judgement” override?

Maybe they’ll tell us something useful that we did not expect!

A: NO. NO. NO. In the past, our required clinical fields have often been perceived as Nuisance. Requiring completion results in answers like: “.” and ”  “, or even “jkljlkj”. The least number of keystrokes to make the stop sign go away. Or it results in hate mail “This is stupid. You are stupid. ” Burned out physicians/APP’s can easily pass the burnout to our IT and informatics team members. Leaving it optional leads to better signal/noise and more thoughtful comments from the rare commenter.

Q7: Whose job is it to review these exceptions and comments? And how often shall we review?

A: We plan to bring these exceptions back to the EMO committee to look at, perhaps 1 to 2 times year and see if it is performing as expected. Also, if we can spot patterns of the most ‘overridden’ alerts, we can look at removing the alert completely, looking to reduce our need for overrides in the first place.

Q8: Shall we give a choice called GROSS (get rid of stupid stuff) in the suppression reasons?

Why don’t we leverage the wisdom of the crowd to finding the lowest value alerts?

A: Unfortunately, doing so may empower our “go fast” physician/APP phenotype: “I hate all alerts, so I’ll choose the one least likely to show up again”. We worry about these “over-suppressers” who over-estimate their ability to catch important interactions and defeat the systematic protection of the EHR. We do NOT plan to offer GROSS as a choice, but instead will look at “Clinical Judgement” frequency (if a LOT of prescribers choose to suppress, there is signal there, don’t rely on individual prescribers to accurately choose GROSS). A subtle point, but there you go.

Q9: Who do we report these decisions to?

Shall we announce it in the newsletter? Shall we get approval from our busy CMO (chief medical officer) council?

A: Machiavelli teaches us, whenever you make a bad change, do it all at once. Whenever you make a good change (this is a good change; ability to suppress alerts customized to the individual prescriber), TAKE CREDIT FOR EACH CHANGE SEPARATELY. Yes, we will announce this in the newsletter as a separate news item every time there is an improvement. As for authority, we have agreed with our CMO’s to bring, on a quarterly frequency, a summary of the changes the EMO committee is making, to ensure they are overseeing the changes. This will come as an FYI, no decisions necessary, as we have established trust that we are not making crazy decisions, based on past presentations this year.

CMIO’s take? This is a taste of the discussion and decision-making at EMO. Maybe you have an interesting or different take on this informatics work? Let me know!

In our monthly meeting, our surgeon informaticist and I were discussing our Electronic Surgical Case Request and Electronic Informed Consent projects, and the swirling, interconnected decisions we are facing, and it occurred to me that we were facing a COMPLEX project with challenging decisions to be made.

In brief, I recall from an HBR article (A Leader’s Framework for Decision-making) that there are simple, complicated, complex and chaotic environments.

• Surgical Case Requests (SCR) are currently scribbled on paper, sticky note, email, many forms – we want to make them electronic, trackable, standardized, accurate, with few to no verbal handoffs
• We know (from others) that Case Requests and Informed Consent (IC) forms should be implemented together, synergistically
• There are several ways to implement SCR and IC, it is unclear which pieces of hardware, and what software packages are best to use in the peri-operative space.
• There is an idea that combining a surgical Consent and an anesthesia Consent (as is done by our Children’s Hospital colleagues) would simplify workflow and eliminate 50% of patient-required signatures, while retaining (or improving) patient-physician discussion of consent.
• A combined consent form is a novel idea in many circles and would require consensus from: Legal, Compliance, CMO, Surgery leaders, Anesthesia leaders, IT leaders to agree on the strategy and tactics
• It is not at all clear that surgery leaders and our 1000+ of surgeons are ready to abandon their (potentially error-prone, but familiar) existing paper/sticky-note/email/text/other-method-here workflow for this new process
• This project MUST be completed in the next 12 months, as per C-suite prioritization
• At a high level, we DO have buy-in from Surgery, Anesthesia, Chief Medical Officer, Chief Operations Officer, all the right stakeholders.

But…

Do we really want to take on “Combine Anesthesia and Surgeon Consents” at the same time as these 2 massive projects? Do we?

In this case, I think we’re encountering something Complex.

How to execute this project successfully?

This is something we are wrestling with right now. One significant decision to make now:

• Whether to use the Burning Platform of the Surgical Case Request / eConsent project to push forward the ‘combine anesthesia and surgery consents’ at the same time, OR to skip it (as it distracts from the major goal of succeeding at Case Requests and Consents across the system

Argument FOR unification of consent

• Reduced time pressure in the peri-op area, where patients have already fasted for hours, mentally prepped for their surgery, and NOW have to meet the anesthesiologist, have a detailed discussion of risks/benefits of anesthesia, and sign a consent form
• Reduced number of signatures a patient needs to sign
• Reduced hardware elements that could go wrong: a electronic signature pad connected to a PC or Workstation on Wheels, an iPad running consent form software on the right patient, a patient portal account running on a smartphone or other patient’s device, receiving a consent form.
• Reduced management of customized consent forms, as instead the anesthesiologist can focus on having a thoughtful conversation and documenting the result in the note INSTEAD of explaining a form and chasing a signature.

Argument AGAINST

• Too much change: eliminating a consent process that has been used for decades (on paper) might result in unintended consequences, reduced quality of documentation, missed steps in the peri-operative suite
• Risk of delay or cancellation: if we bet everything on unified consent and we have a hard-stop disagreement from Compliance office, Legal office, CMO office, Anesthesia Leadership, Surgeon Leadership, Operations Office, Nursing, Patient Advocates, will our timeline be able to survive?
• The IT team may not be able to delete and rebuild 2 consent forms at the last minute if our governance decisions cannot keep up with project mile-stones.

Therefore…

In Complex Environments, leaders must watch for emergence, as there may be no prior guidance “best practice” for THIS situation. One must “probe, sense, and respond.” From early conversations, there are many objections to the proposed consent unification, and we sense that the risk to the project may be too great to insist on adding this additional objective.

In this case, I think we must simplify. There are too many risks to the timeline and major hills we already must climb for the Case Request and Consent projects to be successful. Our metrics will include:

• Improved Accuracy of CPT coding (reduced insurance coverage rejection for incorrect CPT code) and thus $$ we have to “write off” due to clerical or administrative error.
• Reduced patient frustration for above billing errors
• Improved OR scheduling (right CPT code leads to better estimates of how long the procedure will take, and the right amount of time can be set aside)
• Improved matching of surgical equipment to the right procedure and reduced need to “emergently flash-clean equipment” that is not ready

Make Decisions with 70% of Data needed?

• Colin Powell tells us to make decisions when you have 70% of data you need, avoid making a decision when you only have 40% of the information you need. I find this: uncomfortable, and probably about right.

How to explain complexity simply?

• One Pager: This is another example of the usefulness of building a vision of WHY, high level explanation of HOW, predict the potholes in this big project, and explain what is needed by leaders and front line to make this happen, and what will be gained as a result.

CMIO’s take?

Simplicity is the ultimate sophistication.
–Leonardo DaVinci, Steve Jobs, maybe others

Don’t under-appreciate Complexity and how to make decisions differently in such circumstances.

It is a tale as old as time (or at least since the early 2000’s when clinics started installing Electronic Health Records). HEY, my EHR sucks! That other one over there MUST be better. Let’s rip out the current one and put in a new one. SURELY that will fix everything.

First of all, that is a fallacy. 20% of the success of an EHR project is due to the technology. 80% is due to the socio-political skills and workflow designs of those doing the installation.

Secondly, maybe we’re too late, and the NEW system is nearly fully installed. We’re just waiting on the data-load. How much data do you pull out of the current system and push into the new? Easy, right? ALL OF IT! Surely all that typing, mousing, clicking that our physicians and APPs and nurses and staff did entering data CAN’T BE WASTED.

In fact, I’ll make it easy:

Here’s a list of data to pull over

• Problems (clinical diagnoses, billing diagnoses, problem list)
• Medications (historical meds, active prescriptions)
• Allergies
• Immunizations
• Past Medical History / Surgical History / Social History / Family History
• Progress Notes, Hospital Notes, Emergency Department Notes

Done! W00t! Our new system is pre-loaded with lots of useful stuff!

Happy, nāive CMIO moving data around.

Not so fast, Sherlock.

Here are a sample of problems we encountered trying to make this happen in our organization:

PROBLEM LIST

We tried loading ICD10 codes from one EHR to another. Maybe 1/2 of the codes come across okay. Others start with “Adrenal Adenoma” and end up with “Adrenal Mass, Not Otherwise Specified”. In many charts, our physicians complained that “It would have been easier to enter NEW diagnoses rather than fix the details of the ones that imported incorrectly.”

Another issue: sometimes you end up merging EHR’s between two organizations. Then, you’ll get “Diabetes, type 2” and then a semi-duplicate “Diabetes, poorly controlled, type 2” and “Elevated Glucose” and “Diabetes, type 2, well controlled”. And then your physicians end up cleaning duplicates OR worse, just leaving the mess as is.

Medications

We transitioned EHR’s, years ago, from Allscripts Touchworks) to Epic. We pulled 2 million medications out of one EHR and ported it into the other. Unfortunately, data stored in Allscripts was, for example:

Lisinopril / 10mg / 2 tablets / once daily / quantity 180 / refills 3

The data Epic expects on the import was:

Lisinopril / 10mg / total dose: 20mg / once daily / quantity 180 / refills 3

As a result, the third field caused an error, and now the result of the import:

Lisinopril / 10mg / __ (defaulted to 1) / once daily / quantity 180 / refills 3

And the physician using the new system might prescribe the wrong dose. Thus, we hired a team of pharmacy technicians to go through each patient and FIX THE ERRORS. It turns out to be MUCH FASTER to enter an entirely brand new prescription than to correct an imported one. Booooo.

A Human Team for importing data

We ended up hiring a team of abstractors. How did we do this cost-effectively? As UCHealth grew as a system, we would add new clinics and hospitals, often with patients in common (eg, electronic data in 2 EHR’s, in health systems that were coming together). Automation and importing tools are still not up to the task of seamlessly merging data sets (eg: here is a lisinopril prescription from 9/2019, here is another one from 3/2020. Are they the same?). As a result, we thought about the most efficient way to fund a team to do this work. We ended up with:

Pharmacy Technicians, supervised by a Pharmacist.

Import Team work

We would send a team into a clinic, to look at the clinic schedule and import Problems, Meds, Allergies, Immunizations. We decided AGAINST importing Past Medical History, Past Surgical History, Social History, Family History. These last 4 were generally of poor quality. Garbage In, Garbage Out (and costly in person-hours).

Pharmacy Techs do well at meds, allergies and immunizations, and diagnosis selections were easily trained.

Sometimes clinics would pay overtime to MA’s, RN’s and some clinicians in advance of the EHR cut-over (bonus: increased time spent on the newer EHR grew their skills).

The team would abstract charts up to 3 to 6 months while using the new system, thinking that the most complex patients in a clinic would be seen more frequently, and then the bulk of the complex patients would be loaded.

Scanning?

We chose NOT to bring scanned images wholesale into the new EHR. We did a trial for a busy primary care clinic, and scanned 1 month of about 30,000 images. Usage / viewing of those images by clinicians and staff after a year was … ONE PERCENT. About 300 images were ever viewed, and most of the views were insurance cards!!! This is a very low utilization rate for a high cost, slow process for scanning, importing and indexing. Perhaps newer  OCR (optical character recognition) and AI – self categorization tools might help in the future…

Instead, we asked clinicians to do EITHER: A) Incorporate data from old notes/EHR into the new one in their progress notes or problem list. We kept the old EHR live for one year, so that clinicians could cross reference without importing.

And/Or, B) Allow clinicians to “tag” individual scans from the OLD EHR to be individually moved to the NEW EHR. This resulted in a small, manageable list of scans to bring over that were most useful (discharge summaries, consultant notes, critical radiology reports).

Data transitions between EHRs? Hire a team. Maybe give them Red Shirts.

Above: Using Craiyon to illustrate mentorship in the style of Picasso. (Thank you to Dr. V’s 33 charts blog for the innovation of harnessing AI to generate images for lazy bloggers like me)

I had a chat recently with a mentee that was enlightening, I think, to both of us. This new informatics leader was stressed about having a slate of recent failures:

• Medical assistants in clinic their clinic tend to leave their small practice after a year or 2 of working with this person
• Newly hired clinical informaticists (supporting physicians/APPs using the EHR under this person’s direction) were talking about leaving for a different job

However, what came out after further discussion was that:

• These MA’s left to go to nursing school, to physician-assistant school, to physical therapy school
• These informaticists were interested in growing their careers as well
• Those who left often drop by to leave a to-go lunch, or leave gifts

So, which is it? Is this a failure or a success?

Of course, asked in this way, on my blog, in hindsight, the answer is obvious. On the other hand, faced with such situations in a busy, overworked clinic or informatics team, high-performing individuals leaving can be felt as a personal blow. “Oh, I spent so much time growing and mentoring this person over the past year, and THEY’RE LEAVING ME. WHAT AM I DOING WRONG THAT THEY WON’T STAY?”

Sure, it would be important to debrief these folks and make sure you’re not missing an obvious pay gap, or deficiency in the job responsibilities, or needed resources, or unhappy work environment. But in this case, these were all superstar performers leaving for positions that would allow them to grow.

In Good to Great, Jim Collins talks about Level 5 leaders who are humble enough to lead from below: to promote team work and team members and succession plans, and also to put the right people on the bus. Sometimes this means finding outstanding candidates who will outgrow their job and leave.

One could choose to look the employees leaving as a failure: all that expertise is walking out the door. Or, one could choose to see it as a success: we mentored this person, grew this human into their greater potential.

A thought experiment: Wouldn’t it be a tragedy for a superstar MA to spend a decade being a superstar MA, instead going on to become a Physician Assistant? a Nurse? a Physician? Of course, some will want to stay and BE that superstar MA… and that is okay too.

In How to Raise an Adult, Julie Lythcott-Haims notes: “Our children are not hot-house orchids, instead, they are wildflowers of an unknown genus and species.” And, there is nothing we, as teachers, mentors, supervisors can do that is as important as growing them, teaching them effective teamwork, giving them confidence, and letting them spread their wings.

In The Infinite Game, Simon Sinek states, that, unlike the Finite Game, in which the goal is TO WIN versus the other guy, the Infinite Game, the goal is to STAY IN THE GAME. What better way to stay in the game than to grow your future colleagues, where-ever they may go?

CMIO’s take? In being a Mentor, I contend, your goal is NOT ONLY to serve your organization with outstanding informatics work, BUT ALSO to GROW THE HUMANS under your care. Sometimes to grow, they will leave. And what they do after, may astound you.