CPOE and Building a Well-Indexed Order Set Catalog

Hi fellow Clinical Informaticists and other #HealthIT leaders,

Sorry, it's been a while since I've been able to blog much. Been very busy recently, engaging physicians, APRNs/PAs, residents, nurses, pharmacists, and other clinical leaders. Since I had a few free minutes this holiday season, I just wanted to take the time to offer some insights into the links between Computerized Provider Order Entry (CPOE) and order set design and strategy.

Developing a good order set strategy can sometimes take a while. Many organizations go through a gradual learning curve, which unfortunately, can sometimes take years. In general, some organizations will start their CPOE journey with a rudimentary strategy, often based only on the popular med-school mnemonic 'ADCVANDISMAL', that can sometimes leave providers unhappy with their early CPOE exposure. Some hints that an organization may be at the beginning of their order set design journey : 

1. The doctors are using 'ADCVANDISMAL' or pre-existing paper order sets as the only guidelines for building their new electronic order sets.
2. Order sets are quite long, sometimes several (2-3) pages.
3. Providers find themselves spending time searching through these long order sets, looking for the two or three orders they want to place at a particular moment, or using the same order set over-and-over for different clinical scenarios.
4. Providers might have somewhere between 2-4 order sets that they use for all of their ordering needs.
5. There is limited use of headers above sections of orders, to give providers guidance about when to check (or uncheck) an order.
6. There is limited use of pre-checked orders.
7. Providers might complain about 'long order sets', clunky order sets' or 'too many alerts'.
8. Order set names are non-standard format (e.g. one catalog has order sets named "Pneumonia Admission Order Set" and "Hospitalist General Admit order set" and "ED Pneumonia", all in the same catalog.)

Gradually, through trial-and-error, some organizations learn that good order set design takes real work and very detailed planning. So I'd like to offer you a way for you to develop what I call a "well-indexed order set catalog strategy", before you begin your CPOE journey. 

(Remember, providers will want a good experience when they start CPOE - Giving them bad order set design will color their first experiences with CPOE!)

Before we begin, let me warn you that there may be other strategies that may work better for your organization. The strategy described below may work, but it may not be ideal for your organization - especially if you already have a starkly different strategy, in which case there may be a serious learning curve for your providers. Read on, and judge for yourself - But always make sure you check with your local informatics professionals before designing an order set strategy for your organization.

ONE WAY TO DEVELOP YOUR NEW ORDER SET STRATEGY :
To develop a stronger order set strategy, it's helpful to start with a good working definition of the term "order set". Although published definitions can vary (see the ISMP Guidelines for Standard Order Sets), there is a simpler one I can offer up, that still works very well from a functional standpoint : 

"Order set (n.) - a collection of orders used to standardize and expedite the ordering process for a common clinical scenario."

Take a good look at the above definition. Does it work for you? Simple and effective, but before we move on, make sure it looks good for you.

If you think that's fairly reasonable, then let's build an index on this definition. If the concept of "order set" is linked, by this definition, to the concept of "common clinical scenario", then what exactly are common clinical scenarios? 

In addition to good listening, and displaying compassion and empathy, physicians/providers generally have two things they do to actively help patients - Either do a procedure, or write an order. Since we're talking about the orders that physicians/providers write, what are the common clinical scenarios that these orders are used for? The common ones seen in most organizations : 

1. Admitting a patient
2. Transferring a patient 
3. Discharging a patient
4. Working up a complaint or condition
5. Treating a diagnosis
6. Pre-operative or pre-procedure care
7. Post-procedure or post-operative care
8. Protocols - (Allowing registered nurses, pharmacists, or other licensed medical professionals to act on an order or orders on behalf of the ordering provider or attending physician)
9. Other (for those things not in 1-8 above)

So now take a look at the above 9 scenarios. Do they work for you? If they still seem reasonable, then you can then use them to build out your new order set index : 

1. ADMIT - To admit an adult patient to an inpatient level-of-care
2. TRANSFER - To transfer an adult patient to another inpatient level-of-care
3. DISCHARGE - To discharge an adult patient from an inpatient level-of-care to home
4. WORKUP - To work up a common chief complaint (e.g. SOB, abd pain, fever, etc)
5. TREATMENT - To treat a common diagnosis (often the top 50 DRGs)
6. PRE-OP - To treat a patient about to undergo a procedure
7. POST-OP - To treat an adult patient after a procedure
8. PROTOCOLS - To allow a registered nurse, pharmacist, or other licensed medical professional to start/modify/stop an order (or orders) on behalf of a Licensed Independent Practitioner (LIP), Physician Assistant (PA), or resident. (E.g. Med titration protocols, dietary interchange protocols, vent liberation protocols)
9. OTHER ('Convenience Panels') - For other common clinical scenarios not outlined in 1-8 above (e.g. Routine pain control, Anti-Emetics, Sleep Agents, Blood Transfusion, etc.)

You'll notice that for the above nine chapters, these all typically refer only to ADULT patients. Pediatric patients, generally, have different diseases, different complaints, different workups, and different drug dosages (usually with weight-based dosing) - So if you have both adult and pediatric patients, you could potentially have an index that looks like this :

A. ADULT LIBRARY

1. ADMISSION ORDER SETS
2. TRANSFER ORDER SETS
3. DISCHARGE ORDER SETS
4. WORKUP ORDER SETS
5. TREATMENT ORDER SETS
6. PRE-PROCEDURE ORDER SETS
7. POST-PROCEDURE ORDER SETS
8. PROTOCOLS
9. OTHER (CONVENIENCE PANELS) ORDER SETS

B. PEDIATRIC LIBRARY

1. ADMISSION ORDER SETS
2. TRANSFER ORDER SETS
3. DISCHARGE ORDER SETS
4. WORKUP ORDER SETS
5. TREATMENT ORDER SETS
6. PRE-PROCEDURE ORDER SETS
7. POST-PROCEDURE ORDER SETS
8. PROTOCOLS
9. OTHER (CONVENIENCE PANELS) ORDER SETS

Using this hierarchy, you can then start to build out the catalog - I'll use only the adult catalog as an example : 

A. ADULT LIBRARY

1. ADMISSION ORDER SETS

• ADMIT TO MED/SURG
• ADMIT TO TELEMETRY
• ADMIT TO ICU
• ADMIT TO LABOR AND DELIVERY
• ADMIT TO PSYCHIATRY
• ADMIT TO SURGICAL DAYCARE
• ADMIT TO MEDICAL DAYCARE 

2. TRANSFER ORDER SETS 

• TRANSFER TO MED/SURG
• TRANSFER TO TELEMETRY
• TRANSFER TO ICU
• TRANSFER TO LABOR AND DELIVERY
• TRANSFER TO PSYCHIATRY
• TRANSFER TO SURGICAL DAYCARE
• TRANSFER TO MEDICAL DAYCARE

3. DISCHARGE ORDER SETS

• DISCHARGE FROM MED/SURG
• DISCHARGE FROM TELEMETRY
• DISCHARGE FROM ICU
• DISCHARGE FROM LABOR AND DELIVERY
• DISCHARGE FROM PSYCHIATRY
• DISCHARGE FROM SURGICAL DAYCARE
• DISCHARGE FROM MEDICAL DAYCARE

4. WORKUP ORDER SETS (based on chief complaints)

• WORKUP - ABDOMINAL PAIN
• WORKUP - AMENHORRHEA
• WORKUP - BACK PAIN 
• WORKUP - CHEST PAIN
• WORKUP - CONFUSION
• WORKUP - COUGH
• WORKUP - FEVER
• WORKUP - GI BLEEDING
• WORKUP - HEADACHE
• WORKUP - SUSPECTED HYPERCOAGULABLE DISORDER
• ...
• WORKUP - OTHER 
• WORKUP - SHORTNESS OF BREATH 
• WORKUP - SWOLLEN EXTREMITY
• WORKUP - SYNCOPE 
• WORKUP - TICK BITE 
• WORKUP - VAGINAL BLEEDING

5. TREATMENT ORDER SETS (based on common diagnoses or DRG)

• TREATMENT - ACS - UNSTABLE ANGINA/NSTEMI
• TREATMENT - ACS - STEMI
• TREATMENT - AFIB WITH RVR
• TREATMENT - ANAPHYLAXIS
• TREATMENT - ASTHMA EXACERBATION
• TREATMENT - BACK PAIN 
• TREATMENT - CELLULITIS
• TREATMENT - CHF EXACERBATION
• TREATMENT - COPD EXACERBATION
• TREATMENT - FEVER
• TREATMENT - GI BLEEDING
• TREATMENT - HEADACHE
• ...
• TREATMENT - PNEUMONIA - HCAP
• TREATMENT - PNEUMONIA - ASPIRATION  
• TREATMENT - STROKE 
• TREATMENT - SWOLLEN EXTREMITY
• TREATMENT - SYNCOPE 
• TREATMENT - VAGINAL BLEEDING

6. PRE-OP AND PRE-PROCEDURE ORDER SETS (based on procedures)

• PREProcedure - CARDIOVERSION
• PREProcedure - CENTRAL LINE PLACEMENT
• PREProcedure - HEMODIALYSIS
• PREProcedure - INTUBATION
• PREProcedure - PARACENTESIS
• PREProcedure - THORACENTESIS
• PREop - APPENDECTOMY
• PREop - ARTHROPLASTY
• PREop - KYPHOPLASTY

7. POST-OP AND POST-PROCEDURE ORDER SETS (based on procedures)

• POSTProcedure - CARDIOVERSION
• POSTProcedure - CENTRAL LINE PLACEMENT
• POSTProcedure - HEMODIALYSIS
• POSTProcedure - INTUBATION
• POSTProcedure - PARACENTESIS
• POSTProcedure - THORACENTESIS
• POSTop - APPENDECTOMY
• POSTop - ARTHROPLASTY
• POSTop - KYPHOPLASTY

8. PROTOCOLS (allowing a registered nurse, pharmacist, or other licensed medical professional to START/MODIFY/STOP an order or orders on behalf of a Licensed Independent Practioner (LIP), Physician Assistant (PA), or resident.) 

• PROTOCOL - HEPARIN TITRATION PROTOCOL
• PROTOCOL - INSULIN TITRATION (DKA/HNK) PROTOCOL
• PROTOCOL - CARDIZEM TITRATION
• PROTOCOL - PROPOFOL TITRATION 
• PROTOCOL - ALCOHOL WITHDRAWAL
• PROTOCOL - MASSIVE TRANSFUSION PROTOCOL
• PROTOCOL - VENTILATOR LIBERATION

9. OTHER ('CONVENIENCE PANEL') ORDER SETS - For those common clinical scenarios not outlined in #1-8 above, also helpful for using as building blocks in other order sets (e.g. having a routine pain management panel in your admission order set)

• CONVENIENCE - Routine Pain Management
• CONVENIENCE - Routine Anti-Emetics
• CONVENIENCE - Routine Bowel Regimen
• CONVENIENCE - Routine Sleep Management
• CONVENIENCE - Routine Glycemic Control 
• CONVENIENCE - Routine VTE Prophylaxis 
• CONVENIENCE - Routine Blood Transfusion

Having this well-stratified an index will let you build small, short order sets, with only a few orders in each order set. The benefits of such a strategy :  

1. Shorter, faster order sets which can often be pre-clicked (in many scenarios, depending on your local policies), and pre-built with better decision support to better guide providers to better choices.
2. Fewer duplicate-order, duplicate-therapy, and drug-drug interaction alerts = Less alert fatigue.
3. Better ability to share order sets among specialties - Why should the workup for chest pain be different in the ED than on the floor? If one provider builds an order set, shouldn't everyone benefit? 
4. Faster build time and easier maintenance - Need to make sure all admissions to med/surg have a code status order? Only one order set needs fixing, not twenty.
5. Faster CPOE - Docs can breeze through an order set tailored to exactly the clinical scenario they are trying to address

And the disadvantages of this strategy? Your providers will use more order sets, and so having them go through the catalog to select their favorites and use them may take a few more clicks than if they just have 2-3 order sets that they use for everything. But you can always build synonyms that help speed up the alpha-search for these order sets, and I do believe that the many benefits outweigh this small disadvantage.

Of course, if this is a significant deviation from your current strategy, you will want to engage your local leadership to review this strategy, think about the cost of re-training your docs, and going forward with such a new strategy. And if you already have such a strategy - Congrats!

In closing - I hope this has been an interesting discussion on order set indexing, and how it impacts the naming convention, speed of ordering, ability to custom-design decision support, physician/provider experience with CPOE, and ultimately, the ability to continuously encourage physicians to deliver better, evidence-based, updated best practices. 

Thanks for taking the time to read this, and I hope everyone is looking forward to 2017 and what it will bring the #HealthIT and #Informatics communities!

This post is for discussion and educational purposes only - Always consult your local informatics professionals before deciding to adopt an order set strategy. Have any thoughts, comments or feedback? Or want to share your own order set indexing strategy? Feel free to leave them in the comments section below!

Raising a Well-Supported Workflow

Hi fellow Informaticists and other clinical leaders,

Long time no post - But I'm glad that I had some time this weekend to catch up on my blog. Have several pieces in the works, but today's is a roughly 18-minute video I put together on "Raising a Well-Supported Workflow".

Having workflow challenges? Not sure what the impact will be if you change a document? I'm hoping this video will help. Remember, workflow design isn't hard, once you see the big picture. It's a lot like propping up a tent, pole-by-pole - The trick is to know what poles you will need to prop up your tent.

So with that, I'd like to offer up this video for your consideration. Special thanks to Charles Webster, MD from ChuckWebster.com for his awesome definition of "workflow"!

Hope this was helpful to you, our future healthcare leaders! If you have any thoughts or comments, please leave them in the comments section below!

Improving Medication Safety at Transitions of Care

Hi fellow Informatics colleagues (and supporters)!

At some point, most CMIOs, CNIOs, and other informatics professionals get asked to speak about topics related to healthcare technology. One of the topics I'm very passionate about is medication safety, so when I was recently asked by HomeWatch Caregivers and CareOne at Northampton to present on medication safety at transitions of care - I jumped at the chance!

At CareOne Northampton MA - May 4, 2016

Why do medication errors occur? What human factors and systems issues contribute to medication safety issues? And what can organizations do to help reduce them? To help answer these questions, I've posted the slides from my May 4th, 2016 CEU presentation at CareOne in Northampton below, along with some commentary (and helpful links) in between them. If you're looking for ways to further improve medication safety in your organization, I hope these slides are helpful to you!

First, to open the talk - a few slides about the presentation, and who I am : 

And a brief introduction to the important concept of non-maleficence, a principle which helps guide medical professionals in their interactions with patients. (Beneficience = Do good, non-maleficience = Do no harm) - along with an introduction to the landmark IOM report, To Err is Human (Kohn, Corrigan, Donaldson), which to me is a must-read for informatics and other clinical professionals :

Talk about topical - The day before my presentation, Dr. Martin Makary reported in the BMJ ( BMJ 2016;353:i2139, published 3 May 2016) that medical errors are now the third leading cause of death (behind heart disease and cancer) - This article underscores the importance of understanding where errors come from, and how to prevent them!

So first, to understand how to talk about medication errors, it's helpful to talk about how to manage medications correctly : I call it the "Five RIGHTS of medication safety" - Giving the RIGHT medication at the RIGHT dose via the RIGHT route/method to the RIGHT patient at the RIGHT date/time. One could even add the Right Manner, and Right Reason/indication to this discussion, but to keep things simple, I've presented the five biggest sources :

So given that understanding of the goal, why do errors occur? Heuristics aside, what are the challenges in assembling and reconciling a "home medication list" on admission? Let's first look at the Five Rights, which will then help us understand where errors can occur :

Thank you to the Institute of Safe Medication Practices (www.ismp.org) for providing the samples of illegible handwriting above - I highly recommend their web site, which is a treasure trove of important information about medication safety...
Finally, a few other potential sources of error : 

Which then brings us to the discussion on single source-of-truth (SSOT) - A discussion which is key in understanding the challenges, pitfalls, and opportunities in managing medications at transitions of care, and inside an organization : 

... and the importance of maintaining this/these source(s)-of-truth at all times :

This then brings us to the important discussion about medication safety at transitions-of-care - Again, a recent (April 29th, 2016) Washington Post article by Jordon Rau : "Hospital discharge: It's one of the most dangerous periods for patients" - provided the right context for this part of the discussion : 

And finally, this brings us to the very important discussion about polypharmacy and its unique contribution to patient safety issues : 

... which is also supported by this April 22, 2016 NYTimes article on "The Dangers of 'Polypharmacy', the Ever-Mounting Pile of Pills" : 

So what can people and/or organizations do to turn these safety challenges into great opportunities to reduce error? My five recommendations : 

And other resources to look for more information on medication safety : 

For those reading this blog, the above references (with hyperlinks) include : 

1. Institute for Safe Medication Practices (ISMP) - http://www.ismp.org 
2. Health.gov - Office of Disease Prevention and Health Promotion - http://health.gov/hcq/pdfs/ADE-Action-Plan-508c.pdf
3. National Academies Press - Institute of Medicine : To Err is Human Report : http://www.nap.edu/read/9728/chapter/1
4. Agency for Healthcare Research and Quality (AHRQ) : https://psnet.ahrq.gov/primers/primer/11/adverse-events-after-hospital-discharge 

I hope this discussion (and these slides) are helpful to you as you start to explore ways to further improve medication safety in your own organization!

Have other recommendations? Other lessons learned? Feel free to leave them in the comments section below!

Some Factors Underlying Efficient Change Management

Recently I had a great discussion with a non-healthcare person about the role of Informatics in EMR implementation, and what kind of things CMIOs look for to estimate whether a particular EMR implementation will be successful or not.

The discussion was a great opportunity for me to really think about the big picture issues, and try to distill them into something more tangible to a non-healthcare, non-informatics audience. 

What it finally came down to, for me, was the successful planning and budgeting for the whole EMR implementation - both the go-live, and the eventual optimization and continued maintenance that come afterwards. It's not unlike buying a car - To be successful at car ownership, you have to budget for both the car (necessary at go-live) and the gas/maintenance (necessary after go-live to make the car go forward) :

While researching for this blog post, I found out this is one of the reasons why the mandatory price stickers on all new cars (known as the Monroney sticker) must contain both the price of the car and an estimate of the gas mileage :

Not only does this allow consumers to select cars with better fuel efficiency, it also helps a consumer answer the question "Can I afford this car?" before they actually buy it - A major factor for successful car ownership.

With most healthcare technology, it's pretty easy to budget for the car - vendors know this number well - but it's not as easy to budget for the gas. Vendors will often estimate the cost of optimization, upkeep, and maintenance for you, but how do you really know if their estimate is correct? Will you see the same gas mileage in your experience?

This then raises the question - What exactly are the factors that go into 'gas mileage' for an EMR? CMIOs, CNIOs, and other Informatics professionals struggle with these questions all the time, because they are important to help budget for successful EMR implementation :

• Budget well for the ongoing optimization, maintenance, and upkeep - And your EMR implementation will likely be successful.
• Budget poorly for the ongoing optimization, maintenance, and upkeep - And your EMR implementation may be fraught with struggle.

What experienced Informatics professionals know is that a large part of the 'fuel-efficiency' of EMR ownership comes from the organizational change management - How well-suited is the organization to make change? Does it contain the infrastructure and configuration needed to support efficient change management? 

These change management issues are so key to EMR implementation that in 2013, the website www.HealthIT.gov published this great primer on EHR change management :

https://www.healthit.gov/sites/default/files/tools/nlc_changemanagementprimer.pdf 

 ...which provides a great high-level overview about change culture, along with some fantastic references. (A helpful document and a must-read for any healthcare executive considering an EMR installation or replacement!)

But what are the other factors that experienced informatics professionals look for in change management? Are there other factors to look for that help better estimate your gas mileage, and thus your eventual cost of ownership? To help share some insights, I've created the following table, with some factors that I believe influence an organization's ability to manage change efficiently - In estimating the price of your gas, some factors to consider (in no particular order) include : 

While this list is by no means comprehensive, these are some of the bigger factors that experienced Informatics professionals consider before advising organizations how to best budget for their EMR implementations.

In the end, enterprise EMR success depends on correctly budgeting for the purchase, maintenance, and upkeep of your technology. It's not just your go-live that matters. Knowing the price of both the car and the gas before you invest will help you have a successful long-term implementation.

This post is for educational and discussion purposes only - Please consult your own Informatics professional before budgeting for any technology purchases. If you have any feedback, thoughts, or other factors to consider, please leave them in the comments section below!

Should Clinical Informaticists be licensed?

Hi readers,

I was recently talking with a group of informatics professionals about the issue of clunky workflow and 'click burden', which is a constant issue in EMR adoption. The conversation raised a question I've been wondering about recently - Should Clinical Informaticists be licensed? To help answer this question, I thought it would be fun to take a trip back in time and see if history can help guide us. 

Our trip back started recently when I was reading about the history of the area where I live - Northampton, MA, which sits in western Massachusetts, at the foothills of the Berkshire mountains, along the Connecticut River. I was really surprised to learn about the history of a little stream that runs along Route 9, the Mill River - Which in 1874 was the site of a horrible tragedy, which eventually helped contribute to advancements in safety and engineering that we benefit from today.

To start our journey, I'd like to thank Elizabeth M. Sharpe, PhD, the author of this great reference that nicely summarizes the events : https://pvhn3.wordpress.com/1800s/mill-river-flood-of-1874/ 

In short - The Pioneer Valley, as it's known, was once the site of great industrial strength, like many New England towns. Buttons, cloth, brushes, and paper were all produced by factories in this area, and shipped off for sale to other places via a rail system that used to connect the area with other parts of the country. 

And like many industrial areas prior to widespread electricity, these factories depended on waterways for energy. The Mill River, about 15 miles long, was one of those waterways.

So back in the 1870s, a group of local factory owners, disappointed with their inability to produce goods during prolonged droughts, developed an idea : To build a big reservoir up in the hills, in a little nearby town called Goshen - So if there was a drought, the idea was, the water could be let out into the Mill River, and the factories could stay in business.

So the factories commissioned the building of a big, 100-acre reservoir up in the Goshen hills. From the Dr. Sharpe's site https://pvhn3.wordpress.com/1800s/mill-river-flood-of-1874/  : 

"In the absence of state regulation on dam construction, the reservoir company was free to design and build the dam as they pleased.  Frustrated with the $100,000 cost of a design prepared by professional civil engineers, the company opted to dictate their own design to an incautious local engineer who wrote general specifications.  The company then hired careless contractors for $24,000 who made the inadequate design worse.  Despite repairs, the dam leaked and slumped for eight years.  Anxious valley residents who questioned the dam’s safety were reassured by the manufacturers that the dam would hold.”

Sure enough, on May 16th, 1874, the weather had been unusually rainy, and the dam gave way. Millions of gallons of water suddenly spilled down the Mill River, sweeping houses, barns, bridges, roads, factories, and people, and down the river, killing 139 and making over 700 people homeless. The New York Times took two days to figure out what happened (before the telephone), but eventually reported this : 

(NYTimes, May 16, 1874)"ACCOUNTS FROM SPECIAL CORRESPONDENTS.""THE CONSTRUCTION OF THE DESTROYED DAM - THE RUSH OF THE FLOOD DOWN THE VALLEY - THE VILLAGES DESTROYED. PARTIAL LIST OF THE DEAD. MORE BODIES FOUND. PROBABLE LOSS BY THE FLOOD.""Northampton, Mass., May 16. - The beautiful valley of the Connecticut River was laid waste to-day, and five villages totally destroyed. The heavy rain of Friday night and this morning caused a rapid rise in Mill River, on the banks of which were built the villages of Williamsburg, Skinnerville, Haydenville..."

What strikes me most about the story came from the hearings following the disaster : 

"A coroner’s inquest thoroughly investigated the disaster’s cause.  The verdict named five parties at fault: the reservoir company which owned the dam; the contractors who built it; the engineer who provided an inadequate design; the county commissioners who inspected and approved it; and the Massachusetts legislature which chartered the reservoir company without requiring any assurance that it was safe.  There were no indictments, no fines, and no subsequent law suits.  A year after the flood, in 1875, Massachusetts passed its first legislation regarding reservoir dam design, construction, and liability.  Considered weak by today’s standards, the law was, nevertheless, a first step toward safer dams."

And so, through disasters like this (and the similar Johnstown Flood of 1889), eventually America came to learn that all engineers actually needed to be licensed. See the National Society of Professional Engineers page commemorating this achievement here :  http://www.nspe.org/resources/press-room/resources/100-years-engineering-licensure 

As a result, today, the houses we live in, the elevators and cars we ride, and the water we drink has all been designed by a trained and licensed engineer, whose responsibility it was to ensure the successful design and safety of the project.

And so the house, car, and elevator you got into all followed basic engineering principles and started as blueprints, which were tested before they were built, inspected, and approved for use.

Historically, healthcare did not apply these engineering principles to workflow development. Generally, doctors and nurses built these workflows organically, through informal agreements about how to take care of patients made over many years - Typically with no blueprints, no project plans, and no formal approval process. But with the advent of modern EMRs and ACOs, we now need to engineer workflows to a higher standard. 

This brings us to the question of licensing Informaticists. Despite the significant efforts of AMIA, ANIA, and HIMSS to formalize and standardize the role, there still are still a number of "Informaticists” who have no real training on CDS or clinical workflow design. Similarly, there are some people doing CDS and clinical workflow design with no formal Informatics training, or even recognition that they are working as Informaticists (because they have other job titles like “Clinical Knowledge Expert” or “Solutions Engineer”) - 

While certificates, degrees, and board certification in Informatics goes a long way in improving the quality of workflow design, healthcare still has a long way to go in recognizing the importance of this certification, and why it's important to have trained, certified engineers (Informaticists) designing the orders, order sets, protocols, documentation, and workflows in the EMR, to help streamline clinical workflows and reduce click burden.

So the Mill River teaches us that it's better to have a dam built by a trained, licensed engineer, with legal responsibility for the outcome, than to have one built by an “engineer” with no formal training. And this is why organizations seeking to improve click burden and streamline their workflows might be well-served to have trained, certified Informaticists leading their EMR configuration. And to help achieve this primary goal, it's helpful to call Clinical Informaticists what they really are - Clinical Informaticists.

I hope this post has been a fun trip back in history, and helpful to you in developing your own Informatics platform.

Remember these posts are for open discussion and educational purposes! Have any thoughts or feedback? Leave them in the comments section below!

The Red Sneaker Problem - And how to fix it

Hi fellow Informaticists, chairpersons, and other budding healthcare leaders!

There's no question - Healthcare is currently under tremendous pressure to perform. Quality needs to go up, at the same time that costs go down - And fast. In my own humble opinion, it's currently undergoing change at a pace that's hasn't been seen since the inventions of penicillin and vaccinations. 

Informaticists know that information drives behaviors, and the information doesn't just start-and-stop inside the clinical arena. To really drive down the cost of healthcare, we need to work on efficiency at all levels of healthcare. 

So there is a quiet little information problem I sometimes see, that I thought I'd share in today's post, to help you spot it and fix it. I call it the "Red Sneaker" problem.

The Red Sneaker problem sometimes happens, quietly, when a well-intentioned committee, with a well-intentioned chairperson, makes a well-informed decision.

Typically, it starts with someone in an organization learning about some new regulation, or evidence of a way to make things better : "The evidence clearly shows that patients like Red Sneakers, and they heal faster when staff wear Red Sneakers - So if we all wear Red Sneakers, costs will go down, quality will go up, and patient satisfaction will improve."

After bringing the idea to a committee who asks for a few presentations and data on the potential benefits of Red Sneakers, the committee finally votes on the question : "Should all staff wear Red Sneakers?". After some deliberation, the committee votes, and the motion is adopted : All staff will wear Red Sneakers. The committee celebrates the victory, and the secretary documents the vote in the committee minutes. People leave the committee meeting, and through emails and word-of-mouth, other people learn that the committee has voted to approve Red Sneakers for all staff.

The quiet problem that sometimes arises is that the committee was not well-positioned for success. The chairperson is new, and might not understand the parliament or committee position in the governance of the organization. The members may not be clear about the mission of the committee. The committee was not made aware of its responsibilities, authorities, or jurisdiction. And so, the vote was overwhelmingly in favor of all staff wearing Red Sneakers, but...

1. No policy was updated to reflect the new organizational standard of all staff needing to wear Red Sneakers.
2. No budgets were updated to pay for the ongoing use of Red Sneakers.
3. No local suppliers were contacted to establish the availability of Red Sneakers.
4. No employment contracts were updated to require the wearing of Red Sneakers.
5. No staff education was created for staff to understand the new standard and importance of wearing Red Sneakers.
6. No onboarding materials were updated to teach new staff about the importance of wearing Red Sneakers.
7. No workflows were designed to check for Red Sneakers before staff enter the organization
8. No backup procedures were created for staff who arrive without Red Sneakers.

Without any of this background work, the committee still announces the result of their vote, and record it in the committee minutes. Initially, things look good. With enough cheerleading and word-of-mouth publicity, they start to see some adoption of Red Sneakers: 

But without planning for these other reinforcements, Red sneakers were not well-budgeted for. Eventually new staff will come into the organization who don't know about this committee vote, and missed the publicity about Red Sneakers. The few staff still looking for Red Sneakers might not be able to find them in local stores, and there are no backup procedures for staff who forget them. And with no way to support or enforce the use of Red Sneakers, after a few months, the adoption of Red Sneakers starts to dwindle...

And so the entire discussion of the committee and the vote to adopt the new measure have not been effectively implemented. Six months later, committee members notice almost nobody wears Red Sneakers, gradually get a sense that the committee is powerless, and stop showing up to meetings. Especially in healthcare, this can be an expensive way to generate frustration and apathy.

Fortunately, it's fairly easy to prevent the Red Sneaker problem. The first step is to look out for it. If you think your committee(s) might have the Red Sneaker problem, consider some of the following : 

1. Make sure you don't have more committees than you need by ensuring that every committee has completed a yearly charter, and that all committee charters are filed in a central location in your organization, so you can look for ways to avoid overlaps and streamline your committee structure. (If you need a committee charter template to start, you can click here to read my old blog post on committee charters.)
2. Make sure your committee chairpersons have adequate training and orientation before chairing a committee, including some training about parliament, project management, and the quiet-but-problematic red sneaker problem.
3. Solidify your cost estimates before adopting a new measure, by making sure that committee chairs ask for detailed project plans and cost estimates before bringing a measure to a vote. These project plans should address the various tools and strategies you will use to introduce and reinforce the new workflow.
4. Consider having a clinical informaticist, workflow expert, or other process expert to consult or help draft the project change plan and cost estimates before adopting the new measure.

I hope this post is helpful to you in developing your own informatics skills, and supporting excellence in your healthcare organization!

Have any thoughts about workflow adoption issues or clinical governance? Want to share your own stories? Leave your comments in the comments section below!

How to write gourmet policy and procedure

Hi fellow informatics junkies, workflow managers, and other clinical Jedi,

I love watching the Food Network channel. Not only because it lets you watch world-class chefs prepare unbelievable dishes, but because of the business and operational lessons they sometimes impart. Two of my personal favorites are Gordon Ramsay and Buddy Velastro, who not only bring a real love for food, but also demonstrate really smart business and operational sensibilities. I have always believed that healthcare could learn some lessons from the food industry.

With that in mind, today I'd like to address the subject of policy writing. To me, policy is like food -  If you don't like it, and it doesn't nourish you, why bother with it? It's not just enough to taste good - Good policy should also be good for you. 

Also, like food - Good policy creates harmony and brings people together. Holiday dinners are no fun to make if you are the only person making them. They become much more meaningful when you share the labor with your family, and have a chance to talk and communicate while you wash the vegetables and boil the pasta. The same applies to policy writing : It's not just the end result that matters - It's also the road you travel to get there. 

Writing great policy and procedure doesn't have to be painful - It's actually fun once you know the recipe. It can help you create clarity, harmony, and efficiency. So with that in mind, I'd like to offer up a great recipe: How to write a gourmet policy and procedure.

Now remember, because they can become the subject of legal inquiries when they fail, policy is something you should take your time to develop. For this reason, you'll also want to consult your legal advisor before undertaking any changes to your policy process.

Also remember, procedures are workflows - So by writing good policy and procedure, you are mapping out your core operational workflows! If you have an EMR and an Informatics team, you can save lots of time by making sure your procedures are well-written, since they are key tools used to configure your electronic medical record!

Now, before we get to the recipe, just so we're all on the same page - what's a policy, and what's a procedure?

• POLICY = Your standard
• PROCEDURE = How you will achieve that standard

These two are often found together on the same document, because once you define something as being a standard (policy) in your organization, you will quickly need to know how you are going to meet that standard (procedure).

This is where a common question comes up - Q:"Do you NEED to have the procedure on the same document as your policy?" A : No. Some organizations choose to just define policy - And then link the policy statement to a separate procedure document, e.g. "PROCEDURE : Please see the Lippincott Manual, page ____". Either way, if you are defining a policy standard in your organization, that you can legally be responsible for upholding - you should put a lot of thought into how exactly you will uphold that standard. 

Now - Let's get to the recipe!

A. PREPARATION :
The first step to creating a policy is asking the question, "Do I really need a policy?" You generally don't need to create policies for things that are common sense, don't benefit your organization, or impossible to enforce. On the other hand, you *do* want policies for the important operations of your organization, especially ones that are supported by regulations.

Once you've decided that you need a policy, the next step is doing some literature search, starting with your existing policy manual - Does any existing policy already address some or all of the desired standard? You will need to do this to ensure you don't have overlapping or conflicting policies. You will also want to review other current literature, to see if there are any regulations, studies, or best-practices which support the creation of your policy.

If there is no conflicting policy, then next it's helpful to gather the organizational policy template, policy style guide, and any regulations or articles you've found which support the creation of the policy. 

B. DRAFTING THE POLICY :
Once you have clarity on your need for a policy, including the regulations and any other citations which support the creation of the policy, you will want to then take your standard policy template and policy style guide, and start to write the policy statement.

Policy statements, ideally, are short and sweet, and should clearly state what your desired standard is. An easy way to think of writing them is using this template : 

"All __________ will _________ according to the procedures outlined below."

So, as a teaching example, let's make a "Cupcake policy" that makes it mandatory for all patients to get a cupcake on arrival to an inpatient bed : 

Now that you have drafted the policy statement, you will want the reader to figure out how they can achieve this standard by writing a good procedure.

C. DRAFTING THE PROCEDURE (with time/cost/labor estimates!)
To help support our new cupcake policy, we will want to figure out exactly how the organization will support this policy. This is the place where organizations can save a lot of time and money by writing a great procedure that helps create harmony during the policy review process. Remember - procedures are workflows, and working them out regularly will help create workflow clarity, making your policies tools of budgeting, education, and harmony.

The easiest way to write a clear procedure is to use the following template : 

[ WHO ] will/may [ WHAT ] [ where ] [ how ] [ when ] [ why ] [ time ] [ labor ] [ materials ] 

Where : 

• [ WHO ] = Role of the person who will perform this step of the procedure
• [ WHAT ] = Task they will do at this step of the procedure
• [ where ] = (OPTIONAL) Where they will perform this task (e.g. "in a bowl")
• [ how ] = (OPTIONAL) How they will perform this task (e.g. "with a spoon")
• [ when ] = (OPTIONAL) When they will perform this task (e.g. "until smooth")
• [ why ] = (OPTIONAL) Why they perform this task (e.g. "to prepare for baking")

So for our cupcake example, we might start by DRAFTING the following procedure : 

You will notice that by writing it using this template, you have started to answer some questions : 

• Who are the end-user stakeholders? (A: Kitchen staff, couriers, and inpatient nurses.)
• Who will need to help review this policy? (A: Director of Kitchen Staff, Director of Couriers, and Director of Inpatient Nursing)
• What is the cost of this procedure? (A: Time, labor, and materials of each step!)

In fact, if you wanted to get really fancy, you could potentially bring this procedure into a spreadsheet, and calculate the cost of the procedure to a penny!

I highly recommend playing around with your procedure in a spreadsheet like this - You will quickly figure out two things :

• How much, exactly, the policy will cost you (in this case, $326.40/day in materials and labor x 365 days a year = $119,136/year!)
• Where you might be able to save costs in this workflow (e.g. asking a courier to pass out the cupcakes, instead of inpatient nurses, could save you $80-$20=$60/hr savings x 3.33 hours = $200 savings a day x 365 = $73,000 savings/year!) 

Figuring out this cost will help prevent you from approving a policy that you don't have the resources to follow. And once you have this procedure (workflow) worked out to your satisfaction, you can then add the regulations/citations which support the creation of the policy : 

... and bring this DRAFTED policy to the stakeholders for review.

D. DETERMINING THE STAKEHOLDERS
Because this procedure was written with the above template, it's pretty easy to figure out who needs to review this policy before it's brought for final approval - The people responsible for the people who will do the task, usually something like : 

• The Director of Kitchen Staff
• The Director of Couriers
• The Director of Inpatient Nursing

So you will want to add their names to the "Reviewed By:" section of the policy (see below):

... and set up some time with these people to review the new policy. 

E. MEETING WITH STAKEHOLDERS TO REVIEW POLICY
Once you meet with these stakeholders, you will want to review the policy together and ask them three questions : 

1. Can your staff do the task(s) in this procedure?
2. Do you have the budget to pay for the staff to do the task(s) in this procedure?
3. Can you educate the staff to perform the task(s) in this procedure properly?

If the answer to any one of these questions is "NO", then it means that either the policy should be edited, rewritten, or delayed until issues can be resolved.

If the answer to all three of these questions is "YES", then ideally, you would seek their signature under the "REVIEWED BY:" section of the policy : 

In some organizations, you might need to seek additional signatures under the "Reviewed By:" section, such as a person from quality to review the policy name and coding are correct and that the spelling and citations are all correct. To see if there are additional signatures, you will want to refer to your organization's standard policy process, usually kept by your policy coordinator.

F. BRINGING FOR FINAL APPROVAL
Once you have the signatures required for final approval, you will again want to refer to your organization's standard policy process, and arrange for the policy to be approved and published. 

Ideally, there is only one signature required for approval, so that the policy can be briefly reviewed in a committee, approved by vote, and then whoever is authorized to approve policy for the organization then signs it, making the policy an active policy : 

Sometimes, usually for political reasons, some organizations have decided to require two signatures for approval, to create a system of checks-and-balances. While this is sometimes helpful, it can also delay policy approval if you don't have both people in the room at the same time. (E.g. one person might agree to sign the policy after a committee vote, but then the second person later decides not to sign the policy = This ends up delaying the approval and frustrating the committee.)

G. PUBLISHING YOUR POLICY
After approval, the person with authority to give final approval should then follow your organization's standard policy process to make sure that the policy is correctly indexed and published in the organization's standard policy manual.

Sometimes, policies will contain an "ACTIVE DATE:" in the language, to allow for policies to be approved before they become active (e.g. approving a policy in February for a project that goes live in March). If the policy clearly states the "ACTIVE DATE :", then you can place it in (or upload it to) your policy manual before the actual active date. 

When a policy is published to your organization's manual, you will now want to send a notice to the people who will be expected to follow the policy - In this case, the kitchen staff, the couriers, and the inpatient nurses.

Finally, you will want to make sure the stakeholders actually educate their teams about the new policy, and assemble whatever resources are necessary to start the new workflow on the expected start date.

H. MONITORING YOUR POLICY
Policies should be monitored for effectiveness by the stakeholders, as soon as they are approved and published. Sometimes the question arises, "What if someone breaks a policy?". While this is a problem, it should not mean immediate punishment or remediation. Instead, it should trigger an inquiry and discussion of what-went-wrong : Was the policy incorrect? Not educated properly? Not budgeted properly? Incorrectly written?

If the inquiry reveals no problem with the policy, then usually it is just a matter of some re-education or remediation, to correct the issue. This deficiency should still be tracked and noted for future review of the policy.

I. REVISITING YOUR POLICY
Policies should be reviewed at least every 2-3 years, to ensure that they are still effective, properly educated, and properly budgeted for. Sometimes organizations make budget changes that impact policy function - Ideally, you will want to catch those workflow changes as soon as possible, but by making it a habit to revisit your policy at a minimum of every 2-3 years, it will help make sure that your policy is accurate, functioning, and up-to-date with current regulations.


Remember - Good policy reduces cost and creates operational clarity and harmony. Bad policy does the opposite. Always review your policy needs, make sure you don't already have an existing policy/conflict, and review your organization's standard policy process and template before you start writing!

Finally, a great reference (for those seeking more information on policy writing) is Writing Effective Policies and Procedures : A Step-by-Step Resource for Clear Communication by Nancy J. Campbell (1997). It's a big book, but the first few chapters are fantastic in explaining the basics, and the rest of the book is a great reference for how to tackle more complicated policy issues.

I hope this has been a basic, helpful review of policy and procedure development! Always ask your policy coordinator and legal counsel for advice before making any changes to your current template or process! Feel free to leave your thoughts and feedback in the comments below!