Healthcare IT Guiding Principles

I’m no project manager (PM), I promise you that. I don’t like deadlines; I sometimes skip over details that I find boring or monotonous; for the love of all things holy, I do not live for spreadsheets. I believe all of these character flaws rule me out of any project management position. That said, I acknowledge that without project managers, nothing would get done. I’m glad PMs exist and that they’re good at what they do. While I don’t have the skillset or mentality of a project manager, I wholeheartedly agree with a key PM credo: the need for a guiding principles statement for information technology (IT) projects big and small.

It makes sense that when embarking on a big project, participants need some rules of the road to ensure the expected outcomes are achieved on time and on budget. I posit that many of these same rules should be in force even after the project is successfully completed. Experience has taught me that after the excitement of the go-live abates, old habits can creep back into the maintenance and upgrade phases of a given application’s lifecycle. Seemingly tiny decisions and minor fixes can undo hard-won benefits achieved during the initial build. Hence, it’s important to keep our eyes on the prize and keep reviewing guiding principles.

What are some healthcare IT guiding principles? I’m glad you asked! I’m going to focus on the single piece of software that impacts doctors and nurses the most, but these rules are applicable to other technology as well. Of course, when it comes to clinical software, the elephant in the room is the electronic health record (EHR). Almost everyone in healthcare has strong opinions about the EHR that they use. Often, those opinions are well conceived and evidence-based; other times, not so much. Under any circumstances, whatever one thinks about the EHR itself, I promise you that not sticking with agreed upon guidelines when building and maintaining the EHR can make the user experience much worse.

My first and foremost healthcare IT guiding principle deals specifically with physicians: Don’t ask a physician to do something in the EHR unless the physician is the only person who can perform the task. Physicians spent a lot of time learning how to care for patients. For the uninitiated, by “a lot of time” I mean four years of medical school and between three and 12 years of residency and fellowship. I’m happy to configure tech to require physicians to make clinical decisions and document them in the EHR. For example, doctors should order medications in the system, and must enter essential details of the prescription, such as dose, route, and frequency. No one else can make these decisions. Doctors should not have to enter the patient’s weight or the patient’s preferred pharmacy; others on the team can and should perform those tasks.

A corollary to the first HIT guideline is configuring tech to support everyone working at the top of their license: The EHR should promote team-based care, distributing work to those who can do it as quickly and safely as possible. While it may be easiest for the project team to route all refill requests to the prescribing physician, that’s likely not the best way to operate a clinic. Support staff can take a first pass at the requests and potentially add information that the physician will need to assess the request (e.g. Has the patient had a visit in the last x months? Have required labs been resulted? Is the patient asking for something that has been denied in the past?) Healthcare tech should encourage clinicians to work as a team, not in silos.

While I’m no surgeon (reference “I’m no project manager” above), most surgeons I know tell me they always strive to do the same steps for every surgery in the exact same way, deviating only when absolutely clinically necessary. If they’re doing an appendectomy, they always do it the same way. In the IT world, we have a name for this: Standards for workflow, appearance, and tools should be created and followed. Some examples: it’s important that we agree that the color red will routinely be used to call a user’s attention to a dangerous result or very important note. While we can display a patient’s weight in pounds or kilograms or both, it’s important to always maintain consistency so as to minimize weight entry or interpretation mistakes (e.g. does the patient weigh 100 pounds or 100 kilograms?)

A final guiding principle for configuring and maintaining an electronic health record may be a bit controversial depending on the vendor, but I believe it in strongly: Follow the recommendations of the EHR vendor unless there are clinical or operational reasons not to do so. Generally, the developer of the software is an expert in how it should be used. If you don’t believe that’s true, might I ask why your organization paid so much money to implement it? (This is a rhetorical question for discussion only; don’t @ me!) When my EHR vendor tells me most customers who are like my organization do it this way and are successful, why would I not follow suit? The most common answers to this question in the real world are “Because that’s not how we do it” and “That’s not how I like to do it.” I prefer to stick with strictly clinical or operational reasons which must be clearly articulated. Otherwise, I’m following the vendor’s advice.

Do you have other important healthcare IT project and build guidelines? Contact me and tell me about them!