Developing and Approving an Order Set

Hi fellow CMIOs, CNIOs, and other Clinical #Informatics and #HealthIT friends,

Today I thought I'd share some helpful slides from a discussion that very few people write about - Developing and approving order sets.

This is a topic where far too little has been shared openly, so many organizations struggle unnecessarily until they learn through repeated trial-and-error how to do this in a much more smooth, efficient way.

Unfortunately, it also brings up the question about maintenance of order sets : 

• Yes, order sets can help save time, reduce clicks, and reduce unexpected pages from staff, but...
• They can also take a lot of work to develop, approve, monitor, and maintain.

So our agenda for today includes : 

First, what exactly do we mean by 'Order Sets'?

Order sets are sometimes referred to as 'Ordering Tools', since different vendors use different terminology to describe these collections of orders that are used to standardize and expedite the ordering process for a common, well-described clinical scenario.

Because they look so similar (and even share some of their definitions!), Order sets are sometimes confused for order panels, pick-lists, and clinical pathways:

1. Order Set (n.) - A collection of orders used to standardize the ordering process for a common, well-described clinical scenario (e.g. workup, treatment, admission, discharge, prep, postop, protocols, etc for pediatric and adult/geriatric patients.)
2. Order Panel (n.) - A collection of common orders of a specific type, typically designed for inclusion in order sets (e.g. common pain meds, common GI meds, common labs, common nursing orders)
3. Pick-List (aka 'Quick Preference List' or 'Convenience Panels') (n.) - A collection of common orders of a specific type, typically designed for convenience only, that is not related to a specific, well-described clinical scenario (e.g. common pain meds, common IV fluids, common anti-emetics, common lab orders, common radiology orders, etc.)
4. Clinical Pathway (n.) - A collection of order sets used to standardize and expedite the daily ordering process (typically throughout the course of a planned hospitalization) for a defined clinical condition, procedure, or surgery.

Order sets also typically come in two types : 

• Oncology Order Sets - Typically broken out in a separate category, because of the unique, complex ordering needs for chemotherapy and biologic infusions (e.g. monoclonal antibodies)
• All other Order Sets (General order sets) - Typically related to working up common chief complaints, treating common conditions/diseases, admitting/transferring/discharging to/from an inpatient area, preparing for a surgery/procedure, recovering from a surgery/procedure, and special protocols (to automate common, high-risk clinical scenarios where the benefits of standardization and timely delivery of care outweigh any known risks).

For this purposes of this post, we will mostly be discussing the second category above - General order sets. (We could write a whole separate post about the unique needs of Oncology and biologic infusion ordering workflows.)

So before we get to our development discussion, let's first start with our approval discussion - In a typical healthcare organization, who is best-suited to approve an order set?

Many organizations struggle with this question, because there's usually no one person who has all of the time, expertise, and authority needed to approve an order set. I sometimes describe this as the 'Captain Kirk and Scotty' paradox : 

• Captain Kirk = Has all the authority, but little expertise
• Scotty and engineers = Have all the expertise, but little authority

So ultimately, the lesson here is : Captain Kirk, Scotty, and the other engineers have to work together to make the ship run.

Some organizations chose to focus on expediency, by assigning one person or one team - sometimes a clinical officer (CMO, CNO, or both?) or an appointed committee (chaired by a CMO, CNO, CMIO, and/or CNIO?) - But is that enough? Are there any helpful regulations or published best practices, and if so, what do they say?

Unfortunately, there's not much. As of 2024, order sets are still a bit of a mystery to most regulatory agencies. Not only does CMS use the terms "Standing Orders", "Order Sets", and "Protocols" interchangeably, but there are very few published best practices openly available on the Internet. The OHSU ClinfoWiki has some helpful information about oversight and governance in these published pieces :

• "Creating Order Sets"
• "Making Sense of Clinical Practice: Order Set Design Strategies in CPOE"
• "Enhancing Physician Adoption of CPOE: The Search for a Perfect Order Set"

... but while there's some helpful information about oversight committees and mentions of templates, these articles don't contain much concrete detail about the exact development or approval processes, or samples of templates.

So the most concrete regulatory guidance seems to come from the Centers for Medicaid Services (CMS) 42 CFR § 482.24, under section (3) which states : 

So if CMS expects the Medical Staff and the hospital's Nursing and Pharmacy leadership to be 'reviewing' order sets - Does that mean three committees need to be involved in the review/approval process? (E.g. Medical Board/Medical Executive Committee, Nursing Council, and Pharmacy and Therapeutics?) Or should those committees delegate a separate team to just focus on order sets? 

Or should the clinical leadership of those areas (e.g. CMO, CNO, and VP of Pharmacy) approve the order sets? Even if they have the time and expertise to approve order sets, do they have the time to develop them? And if they don't have the time and bandwidth to 'get into the weeds' to develop them, how can they feel confident about approving them?

And what about the other supporting departments in a clinical enterprise - Laboratory, Radiology, and other ancillary services? When the OHSU ClinfoWiki article on "Creating Order Sets" says, "They have their needs thoroughly examined by their practice management oversight group, nursing, support staff and anyone who might be affected by the order set," who exactly might be affected by the order set? After all, don't doctors just write orders, and other people in the organization have to execute/follow-through with them?

Well, it's not that simple. Clinical staff affected by the order set include both : 

• The staff writing/creating orders (typically Ordering Providers, including Attendings, Residents/Fellows, Advanced Practice Providers/APRNs/PAs/CRNAs etc.)
• The staff following/executing orders (commonly everyone else in a clinical enterprise, including Nursing, Pharmacy, Lab, Radiology, Bed Management, Case Management, Dietary/Nutrition, and other ancillary support services)

Some doctors initially bristle when they learn that other specialties are involved in reviewing and approving their order sets. But if we take a step back - Order sets create patterns of clinical care and utilization that have an impact across the whole organization, so it shouldn't be a surprise that other people are involved in reviewing the best practices, and planning utilization and resource needs to execute and follow-through with those orders.

So how do we make sense of this? It helps to imagine a 'pyramid' of delegation and oversight, one that helps to connect Captain Kirk (all authority, little expertise) with Scotty and his engineers (all expertise, little authority) :

... which is a very basic operational unit that can be employed in developing a process for reviewing and approving order sets. So in a typical clinical enterprise, there are similar pyramids for the major clinical disciplines involved in the delivery of care (Nursing, Pharmacy, and Physicians):

Note there are also similar pyramids for Lab, Radiology, and other Ancillary Services (such as Physical Therapy, Occupational Therapy, Dietary/Nutrition, Case Management, Social Work, etc.) :

So now, let's see if we can answer the question : Who exactly is affected by an order set? Well it depends largely on the complexity of your order set. Small, short order sets typically have fewer stakeholders, and larger, complex order sets typically have more. 

Exactly who needs to participate in the discussion will depend on the type(s) of orders in your order set. You can create a very helpful order set development template by identifying and aggregating your most common order types. Most healthcare organizations can divide up all patient care orders into one of sixteen (16) groups : 

Since each order type has a unique function, usually executed/performed by a unique stakeholder - You can then take these sixteen (16) order types, import them into a spreadsheet, and next identify the common stakeholders for each order type : 

Once you've identified the common stakeholders for each order type, you can then create a standardized order set template, that not only helps define expected standards for each order type (e.g. medication orders with medication doses, routes, frequencies, etc.), but also the stakeholders necessary to participate in the review and approval of the order set :

Once you have this template, you can first try it out with a simple order set, say, with just a Procedure order, some Activity and Nursing orders, some Diet orders, and some IV fluid orders :

Or, you can try it with a more complex order set, one that includes : ADT orders, Code Status orders, Procedure orders, Activity orders, Blood Bank orders, Nursing orders, Diet orders, IV Fluid orders, Medication orders, Laboratory orders, Diagnostic Radiology orders, Consult/Referral orders, and Discharge Education orders -

This is helpful when trying to plan new order sets, so you can identify who to invite to your build discussions.

Now, since I'm discussing order sets, I thought it would be helpful to mention the surprising importance of solid, well-planned naming conventions. 

Early in my Informatics career, I would have never have guessed the importance of naming conventions. A few people warned me, but at first I was skeptical. I actually once said something like this : "What does it matter, what you call it? As long as they can find it!"

What I didn't know at the time (and learned with experience) is that naming conventions : 

• Determine the size of your order set library - More coarse/vague naming conventions result in fewer order sets, and more specific/granular naming conventions result in more order sets.
• Determine how easy it will be for your users to find (and bookmark) the order set.
• Help determine whether you are clearly building a time-saving order set - Or if you are confusing it for a Pick-List, Order Panel, or Clinical Pathway. 
• Strongly influence the number of clicks and unexpected pages your users will experience - The more clear and specific the naming convention is, the more you can pre-configure and pre-click default settings (so your users don't have to!)

Knowing that well-described, scenario-specific order sets help reduce clicks and unexpected pages more than general Pick-Lists (aka 'quick preference lists' or 'convenience panels'), I thought I'd share one way to index your order set catalog, based on your most common patient types, common chief complaints, common treatments, common surgeries and procedures, and common protocols :

So with that - First, some helpful take-home reminders : 

... and a few more to consider as you create and develop your governance and order set development, review, and approval processes with your Clinical, Legal, Compliance/Regulatory, Finance, and other leadership :

I hope this quick review has been helpful and provides some helpful food for thought for your own team discussions! Since there is not much written about this subject, please feel free to share feedback in the comments section below.

Remember, this blog is for educational and discussion purposes only - Your mileage may vary!

Have any experiences building order sets, leading order set teams, or creating or an order set development and approval process? Feel free to share any helpful feedback or experiences in the comments section below! 

Strong Recommendations for new Applied Clinical Informaticists, Part 2 of 2

 Hi fellow CMIOs, CNIOs, and other Applied Clinical #Informatics and #HealthIT friends,

Today, I thought I'd share the second half (next ten suggestions) of my general advice to new Applied Clinical Informaticists, and other people interested in smooth clinical #workflow design. 

Strong recommendation #11 (of 20) below involves understanding the inseparable, symbiotic relationship between Information Technology (IT) and Information Science (IS), the discipline that drives Applied Clinical Informatics. While it's tempting to think only one is more necessary or relevant than the other, they are both equally necessary and relevant - You cannot have one without the other. 

Coming in at #12 is the strong recommendation (below) to understand the difference between the 'seeds' of good ideas, and the 'soil' (operational infrastructure) necessary to grow those seeds. While operational infrastructure is not always a high priority, neglected infrastructure can lead to frequent project delays, project failures, and inability to move forward. Take some time every year to look carefully at operational infrastructure, and make sure you devote the time and resources necessary to be able to grow the seeds of good ideas. 

Strong recommendation #13 (of 20) below sometimes becomes more visible after a few years in Applied Clinical Informatics, but it addresses the relationship between inconsistent or incomplete workflows, and burnout (moral injury). Especially in routinely high-risk, high-stress operations, your clinical teams will always appreciate having a smooth, predictable, well-understood pathway (workflow) from problem (point A) to solution (point B). Tangled, confusing, or incomplete workflows only create stress and confusion. Having well-designed, well-developed templates will help you make sure you're covering all of your bases, and that every step of your workflow is well-planned, clear, and complete.

My next strong recommendation (#14 of 20) below is just to be prepared to answer common questions about "Why do we need an interdisciplinary Applied Clinical Informatics team?" While there are many reasons, six of the most common include :

1. Project Intake / Procurements that require additional support or workflow analysis / evaluation to help ensure the technology doesn't already exist (in your organization), and to help ensure proper scoping, budgeting, stakeholder identification, resource allocation, alignment with safety or compliance needs, and expected outcomes. 
2. Special Event Workflow Planning (e.g. Planned maintenance or unplanned downtimes, planned upgrades, or project go-lives)
3. Complex IT Tickets that require workflow updates / modifications (often span areas with multiple stakeholders)
4. Complex Projects that require clinical translation, terminology work, stakeholder identification and alignment, or workflow updates/modifications.
5. Ongoing maintenance of existing configuration / workflows to meet CMS/TJC regulations (and other payer and user requirements), that requires continuous staff engagement with multiple stakeholders across different areas/specialties. 
6. Helping to ensure clinical workflows are aligned with the clinical, HIM, coding/billing, and revenue capture needs of the organization.

To have the skills and expertise necessary for these common functions, you will need an Applied Clinical Informatics team. Knowing some good reasons to have such a team will help support the discussions about how to build one. 

Strong recommendation #15 (of 20) for new Applied Clinical Informaticists (below) is to really care about design. Cooking food is not enough, you need to care about cooking great food. While discussing details is sometimes seen in healthcare as 'getting too into the weeds', our clinical teams need you to care about the details, so that you can develop the complete blueprints that will help technical teams to build great workflows. Also : Try to resist the urge to use short-term solutions for long-term problems - While they might temporarily help, they usually create workarounds that then need even more work to fix.

At #16 is my strong recommendation (below) to know the sixteen (16) most common (CPOE) order types. These are the basic building blocks that work together to build all of your clinical worfklows. It's very helpful to know what they are, what they do, how they work together, and when to use them. Many incomplete workflows come from not including one or more of these order types in an order set, order panel, or other ordering tool, so you can help improve workflow design by including all sixteen order types in an order set template, and then using that to guide the development of all of your order sets. *Note : Not every order set will use all sixteen order types, and you will only use the ones you need to address your desired clinical scenario. Having all sixteen types in a template (for developing your order set blueprints) will help create consistency and completeness for your clinical teams. 

My strong recommendation #17 (of 20) below is simply not to minimize the complexity of ordering tool ('order set') requests. I'm often fascinated by the small requests that have the largest operational impact, and thus require more time and effort to plan and execute than most people have budgeted for. Setting realistic expectations is the first step to good planning, so do your worfklow (gap, current-state-future-state) analysis early, and be prepared to inform your requestor when a project is larger than originally anticipated. 

Strong recommendation #18 (of 20) below is simply to consider how you will manage the intake of maintenance tickets and new project requests, from a variety of stakeholders. Navigating HealthIT (and Applied Clinical Informatics) often means managing the competing interests of : 

• Software vendors
• Patient/Caregiver input/feedback
• User input (from multiple stakeholders)
• Contracting and Payer Updates
• Formulary Updates
• Practice Onboarding
• Institutional Decisions
• Federal, State, and Department of Public Health regulations
• Evidence-based best practices
• Institutional policies and bylaws
• Privacy and Security Needs
• Quality Reporting
• External advisory organizations (e.g. The Joint Commission, Leapfrog, etc.)
• Vendor choices

... so you will want to consider all of these potential sources of change in your intake and prioritization processes.

Nearing the end, my strong recommendation #19 (of 20) below is to learn the most common types of Computerized Provider Order Entry (CPOE) order modes. Ideally, providers would always enter their own orders, but there are some very important, very legitimate reasons (clinical scenarios) why they sometimes cannot (without delaying necessary patient care). Understanding these reasons (and scenarios) will help you create and support compliant and safe order entry workflows all across your organization.

Finally, my strong recommendation #20 (of 20) below is simply to empower a clinical leader. Whether they are a nursing leader, physician leader, APP leader, radiology leader, laboratory leader, pharmacy leader, or other ancillary staff leader - they are all important and deserve your support. Usually, they are already great clinicians - Help them learn leadership skills, and they will be better leaders, and help you solve more problems. Skills like : 

• Reading a bylaw / policy
• Writing a bylaw / policy
• Reading a budget
• Planning a budget
• Writing a charter
• Chairing a committee
• Planning an agenda
• Project and change management basics
• Documentation and coding basics
• Hiring a staff member
• Managing a staff member

... can go a long way to long-term success for any leader. If you see a new clinical leader, make sure you reach out to them and support them as they grow - This will help empower leaders to retain staff and solve problems.

Okay, along with my first ten recommendations, I think these additional ten above cover my top twenty (20) strong recommendations for new Applied Clinical Informaticists seeking to design smooth workflows. If you have other suggestions, please leave them in the comments section below!

Remember - This blog is for educational and discussion purposes only, and is not formal advice - your mileage may vary. Have any other helpful ideas, suggestions, or experiences you'd like to share? Feel free to leave them in the comments section below!

Intro to CPOE and Order Sets

Hi to my fellow CMIOs, CNIOs, Clinical Informaticists and other HealthIT and clinical friends,

Order sets can be a real gift to modern medicine, but only when they are designed by experienced, capable Clinical Informaticists and Analysts, in conjunction with the clinical end-users. Usually, this requires more work and planning than most people are aware of - until they dive into the waters themselves.

So for anyone who's ever had to explain the work it takes to produce good, evidence-based order sets that support smooth workflows with minimal clicks - I thought I'd share this cute little video I produced recently. Think of it as an easy way of teaching some of the basics to newcomers : 

This is the strategy I've used professionally to create great, evidence-based, easy-to-use order sets that give my fellow physicians the right guidance and confidence they need to navigate even the most complicated workflows. Feel free to share with anyone who's new, or looking to learn more about how good workflows and decision support strategies are designed. 

Have any secrets of your own? Feel free to share them in the comments field below!

Remember, this blog is for educational purposes only - Your mileage may vary. Have any other comments or feedback? Please 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!

What is your EMR documentation index costing you?

It's all about the details. One of the things that I really love about front-line clinical Informatics is the remarkable insights you get into clinical operations - and how the tiniest, seemingly trivial design elements can strongly influence the cost and quality of patient care, as well as the cost of maintaining your EMR. 

When I first started, I didn't fully understand this relationship, and the focus of my attention was less on the names of notes and order sets, and more on their content. Fortunately, a respected Informatics colleague gave me this advice, early on :  "If you haven't struggled with designing a naming convention or a documentation index, you haven't done your job." 

It took me a while to understand exactly what this meant, but through years of experience, it's become much more clear to me. So for educational purposes, I thought I would share the story of how I was recently reminded of this lesson, when I saw the following posting on a popular Informatics listserver (paraphrased here for brevity):

'I would appreciate your input on the approach you have taken to your folder or ‘hierarchy’ structure for documentation mapping.
We have robust use of our EMR in both the inpatient and outpatient setting. I have seen both ends of the spectrum when it comes to hierarchies:  Minimal number of note types to a very high level of specificity. We fall in the latter category and are always looking for ways to streamline and strike the right balance. Can you share the approach your organization has taken in this space? 
This may, in part, depend on how robust the search tools are within each EMR but I have some basic questions:

• Do you have Outpatient notes separated from Inpatient Notes?
• Do you separate notes by medical specialties?
• Do you distinguish between a Resident and a Staff note? What about a Medical Student Note? (Do you take an alternate approach to distinguish between these such as the ‘signature line’ in the note proper or the template used for the note?)'

My response reminded me about how much the years of experience had taught me about designing naming conventions and documentation indexes. My paraphrased response is below : 

[ START OF RESPONSE ] 

This is a great question! You have a great opportunity in front of you - This is the essence of what we do - Make it intuitive for people to understand and find their notes in the vast sea of information that is an EMR!

I’ve never been given the same challenge (although it would be a good one!), but I think I would start with a few guiding design principles : 

1. The name of the note should follow a standard naming convention.

2. The index of the note should be intuitive enough for both users and managers to be able to quickly find the information they need.

With those principles in mind, I might then use the Bell Labs North American geographic telephone number model (e.g. (xxx) xxx-xxxx (area code - prefix - identifier)) for paradigm inspiration, and start by [DRAFTING] an index like this: 

Document Name = [ Geographic level-of-care ] + [ Setting ] + [ Role ] + [ Name of note ]

Where :

• Geographic Level-of-care = Where the patient is registered, e.g. Inpatient or Outpatient,
• Setting = What unit the patient is registered in, e.g. Med/Surg, Cardiac Telemetry, ICU, Childbirth, Nursery, Pediatrics, Psych/Behavioral Health, etc
• Role = Role of the documenter, e.g. Adult Hospitalist, Pediatric Hospitalist, Intensivist, ED Nurse, ICU Nurse, Med/Surg Nurse, etc.
• Name of Note = Common name of note, e.g. Admission H&P, Daily Progress Note, Discharge Summary, Consult Note, etc.

So, for example, you could use this naming convention to design a document index like this :

• Inpatient - Med/Surg - Adult Hospitalist - Admission H and P
• Inpatient - Med/Surg - Adult Hospitalist - Daily Progress Note
• Inpatient - Med/Surg - Adult Hospitalist - Discharge Summary
• Inpatient - Med/Surg - Adult Hospitalist - Medical Consultation
• Inpatient - Med/Surg - General Surgeon - Admission H and P
• … etc…

The reason I would probably avoid specialty, and instead use role, is because some specialties fill multiple roles (e.g. Med/Peds specialists might work one day in the role of an Adult Hospitalist, and the next day in the role of a Pediatric Hospitalist) - 

So if you decide to use this format, then, the strategic question will become : What exactly is your organization's list of roles? 

• The more roles you have, the more expensive it will be to maintain your documentation, but the happier your docs will be having documentation designed just-for-them, and the easier it will be to collect role-specific quality indicators.
• The less roles you have, the cheaper it will be to maintain your documentation, but your docs may not be as happy having to accommodate to a one-size-fits-all approach, and the harder it will be to collect role-specific quality indicators.

So you will need to strike some sort of balance between the two. On the most cost-effective, conservative side, you might have very generic roles like : 

1. Inpatient - Med/Surg - Attending - Admission H&P
2. Inpatient - Med/Surg - Attending - Daily Progress Note
3. Inpatient - Med/Surg - Attending - Discharge Summary
4. Inpatient - Med/Surg - Consultant - Consult Note

And in the happy-medium, make-the-docs-happier and collect-more-role-specific-quality-indicators range, you might have roles like : 

1. Inpatient - Med/Surg - Adult-Hospitalist - Admission H&P
2. Inpatient - Med/Surg - Adult-Hospitalist - Daily Progress Note 
3. Inpatient - Med/Surg - Adult-Hospitalist - Discharge Summary
4. Inpatient - Med/Surg - Adult Hospitalist - Consult Note

And finally, on the most-expensive, docs-might-love-it-but-nobody-can-afford-it side, you might have roles like : 

1. Inpatient - Med/Surg - Adult-Hospitalist - Dr. Stanley - Admission H&P
2. Inpatient - Med/Surg - Adult-Hospitalist - Dr. Stanley - Daily Progress Note 
3. Inpatient - Med/Surg - Adult-Hospitalist - Dr. Stanley - Discharge Summary
4. Inpatient - Med/Surg - Adult Hospitalist - Dr. Stanley - Consult Note

For provider satisfaction reasons, I generally wouldn't recommend the first approach, and for cost reasons, I generally wouldn't recommend the third approach. Naming conventions and document indexes with provider names means you will be spending a lot of time and resources maintaining a much larger set of order sets or documentation than you might have budgeted for.

Whatever strategy you decide to employ, you will be living with the decisions for a long time, so I recommend really spending some time, drafting your naming convention and documentation index, and present it to both your clinical and administrative leadership for approval, before moving forward.

Hope this helps! Good luck!

- Dirk :)

[ END OF RESPONSE ] 

So gradually, you start to learn how these tiny, seemingly trivial design details impact the cost of care and maintenance of your EMR, and so you look out for them and look for ways to help cut costs and still maintain provider satisfaction. 

Please note : Other responses to this question included recommendations about using LOINC coding standards to assist with developing industry-standard file naming conventions. This is great advice, and helpful in achieving documentation harmony, especially if you are planning on a HIE or exchanging documentation with other organizations. You can read more about LOINC by going to their web page : 
http://loinc.org/international

Anyway, this was just a very basic introduction to some EMR design issues, and how they impact the cost of EMR maintenance - but I hope this story will be helpful to you in tackling your own naming convention and documentation indexing challenges!

Converting paper order sets to electronic

If you're reading this, I hope you're the person in your institution trying to "convert the paper order sets to electronic ones".

Don't worry - you're perfectly normal. The job is usually a lot harder than it looks. And no, you're not the only one who hears, "Why can't you just take the paper order sets and put them on the screen?"

(Most people think it's simple, until they actually start to dissect the order sets.)

First, let's start with some of the challenges of paper order sets :

1. Paper order sets generally keep multiplying - Let's say you decide to fix the paper order sets, and so you need to take the old versions "off the shelves". Beware - People tend to make copies of paper order sets. So the old ones can turn up weeks and months later.
2. Paper order sets are often engineered differently - In the electronic (CPOE) world, orders are very concrete. You may have specific safety features put into your electronic PCA (Patient-Controlled Anesthesia) order. How will you put those safety features into your paper order set? You may also have hidden "protocols" in your paper order sets. What will you do with those protocol (conditional) orders? 
3. Paper order sets are sometimes ignored, after a hospital "goes electronic" - If you ignore your paper order sets, what will your hospital use during electronic downtimes? Can you afford not to have paper backup order sets, if your OR/ED are busy?

Believe it or not, how you address these paper-order-set problems will be vitally important in your long-term electronic success. Ignore the paper order sets, and you will miss an opportunity to really set up a robust electronic platform.

Let's look at each of these issues in a little more detail :

1. The "Multiplying paper order sets" -

This is a phenomenon many organizations struggle with. The solution : Centralize all of your order sets on one common electronic web site, and publish them as non-editable .PDF files. Create a clinical policy where "If it's not on this site, it's not an acceptable order set".  It will take you a while to get the site together, and organize all of your paper order sets there, but in the end, you will have a way of controlling the paper order sets in use. 

2. The "Engineering differences" between paper and electronic order sets

Some organizations, on going electronic, focus on developing electronic order sets, while the paper order sets continue to be produced in the way they "always have been built". If you have two separate processes (an electronic and a paper process), the problem is that you will start to have significant engineering differences between the two. 

If you have different paper and electronic order sets, you will then encounter :

• Paper order sets that don't meet the engineering standards needed for order entry in your EMR, so they will be very hard to "send-to-pharmacy-so-someone-else-can-do-the-order-entry"...
• Paper order sets that don't match the electronic order sets
• Two cultures : Docs who use electronic order sets, and docs who use paper order sets. (If your organization does a "flip-the-switch" approach to EMR/CPOE, then this won't apply to you. If you do a "gradual conversion", then this will apply to you.)

The way you fix this, of course, is to develop simultaneous paper and electronic order sets. Set up your informatics platform, update your policy on order set development (to include paper and electronic order sets), and ask your informaticists to develop the paper and electronic order sets simultaneously. Have them tested by the same people, and approved by the same committee. This will ensure that they match, and even if you are a "100% CPOE" organization, you will still appreciate having matching paper order sets during electronic downtimes.

Remember, the solution isn't to make electronic orders that mirror your bad paper processes. Make good, solid, and safe electronic orders, and then use those in your updated paper order sets.

A final tip : Embedded "protocol" (conditional) orders generally need to get pulled out of the paper order sets, before you can "make them electronic" - and you will need to decide what to do with those : A. publish them as new protocols, or B. throw them out. This will take work and can be politically challenging. 

3. The "Ignored Paper Order Sets"

Some organizations, on going electronic, ignore the paper order sets, thinking, "We don't need them anymore, right?". My advice : Don't ignore them. Not only will you need to figure out what your pharmacy will do if they end up getting faxed paper orders, but you will still need them for computer downtimes.

If all of this sounds complicated, and it sounds like a lot of work, you're right - It is. This is why order sets are the political and organizational challenge that they are. A good informaticist can help sort out the issues and put a plan and process into place for your organization, where it doesn't have to be too painful. Unfortunately, because healthcare doesn't have standards in clinical processes, every organization handles this conversion differently, and as a result, order sets are notoriously hard to standardize. (Think of them as a "custom-fitted suit".)

One last tip : Beware the "quick fix" - There are consultants who will "easily and quickly convert your paper order sets to electronic ones". The way they usually do this is by taking the paper orders, no matter how they are engineered, and simply build new electronic orders that match them. In the short term, this may appear to work, but in the long term, it may leave the nurses with orders which are unclear (and may create extra pages to doctors to clarify), since some paper orders are not as well-defined as their electronic counterparts. You may also miss out on the opportunity to streamline your clinical processes, and miss out on the time and cost savings that an EMR can really bring. My recommendation : Build the new paper order sets to match the engineering standards of your electronic order sets - Not the other way around. 

As always, my advice with order sets : There are no quick fixes. Hire a good informaticist to help you with this. :)

Hey, by the way, I'm open for questions - If anyone has any EMR conversion or informatics questions that you'd like to chat about, feel free to leave a comment here or email me. I'll try to devote my next posts to reader questions! So send me stories, questions, or whatever else you'd like to discuss in upcoming posts - I look forward to hearing from folks! :)

Why not let docs have their own order sets?

Last week, I was asked a question I'd been asked many times before, by someone who was helping another hospital set up their EMR :

"Why shouldn't we let our docs make their own order sets?"

The reason I was asked this is because many EMR packages have this feature, where docs can make their own order sets for their own convenience. 

REASONS TO LET DOCS MAKE THEIR OWN ORDER SETS :

1. Every doc struggles with efficiency, and making your own order sets certainly is tempting. Why not make order sets that accomplish exactly what you want? After all, if I'm a practicing physician, and I know what orders I 'always put in' in certain scenarios, why shouldn't I be able to make my own order sets?
2. We could save so much committee time if the docs could just make their own order sets!
3. If the docs could make their own order sets, they would probably feel "more comfortable" with order sets and CPOE, in general - Wouldn't this help us with our EMR implementation? Wouldn't we get a higher CPOE rate faster?
4. It would save the time and labor of converting their old paper order sets - (Which, as I've discussed in past postings, are often loaded with embedded protocols which are expensive and time-consuming to engineer out!) - Just let the doctors make their own order sets!
5. If docs could make their own order sets, then they probably wouldn't blame some poor informaticist for making a bad order set for them.

REASONS NOT TO LET DOCS MAKE THEIR OWN ORDER SETS :

1. If every doc can make their own order sets, you have no centralized mechanism for clinical decision support. For example, if your pharmacy previously paid a lot for omeprazole, and it suddenly gets a good deal on pantoprazole, you will probably want all of your doctors to take advantage of the cost savings by steering them towards pantoprazole (when backed by good evidence) - If they all have their own order sets, you won't be able to help guide physician behavior and take advantage of this cost savings. 
2. If every doc can make their own order sets, you also have no centralized mechanism for standardizing care. E.g. an appendectomy could get very different care, depending on which physician was using which appendectomy order set. (Most hospital administrators are trying to standardize care to improve quality and reduce costs.)
3. Order sets need to be maintained regularly, to be kept safe, evidence-based, and efficient. If every doc can make their own order sets, you may quickly end up with many, many different order sets which can be a challenge to maintain, from a technical standpoint. What are you going to do when new guidelines suggest you should be using different drugs to treat pneumonia? How will you find which order sets you need to update? Do you have the resources to keep ALL of your order sets updated? 
4. If every doc can make their own order sets, you will miss out on the opportunity to teach your physicians what informatics is, and how they can improve their own care through evidence-based practice and standardization of processes.

I will admit, as a practicing physician, myself, there are times where I wish I could just make my own order sets. But I will also admit that being challenged on my own order sets is a great learning experience, and ultimately, sharing the discussion with my colleagues, and reviewing the literature is the best learning experience of them all. 

(Apparently I'm not the only one who frowns on personal order sets - A final web page, worth reading even though the author is unclear and this looks more like a comment than a legitimate argument : 

http://www.informatics-review.com/wiki/index.php/Personal_Order_Sets) 

Ultimately, every hospital will need to make this decision for themselves, but remember, as I said - With order sets, there are no free lunches. The rule still applies. :)

Top things to do with your new CMIO

Dear CMIO-owner,

Congratulations on your new CMIO! With a few simple care instructions, your CMIO will serve you well and last a long time.

Here are some of the things you can do with your new CMIO :

1. Ask him/her to help design and develop an informatics platform for your healthcare organization.
2. Ask him/her for advice on how to budget for your next clinical IT project.
3. Instruct him/her to do clinical workflow analysis before you implement your next EMR rule.
4. Ask him/her for expert advice on clinical decision support - What it is, and why it could help your hospital.
5. Ask him/her to help fix and update your order set process to include evidence-based order sets.
6. Ask him/her to help dissect and improve your paper order sets.
7. Ask him/her to help design training curriculum for your physicians, and develop a training plan.
8. Ask him/her about "EMR Governance" and why people seem to write so much about it.
9. Instruct him/her to attend your Medical Executive Committee meetings and give expert input about clinical workflow issues.
10. Ask him/her to develop ARRA/HITECH educational summaries for your senior leadership.
11. Ask him/her to develop EMR implementation strategy.
12. Ask him/her for policy help in developing policies needed to support your EMR.
13. Ask him/her "What is informatics?" and "Do we need it?" and "Is this something other people should know about?"
14. Ask him/her to help develop physician buy-in for CPOE, Order Reconciliation, and other enterprise-wide EMR projects.
15. Ask him/her to build approval policies for your clinical tools.
16. Ask him/her to manage software upgrade projects.
17. Ask him/her to design informatics education materials for your department directors.
18. Ask him/her to network with other CMIOs to look for workflow solutions that meet the tough compliance questions.
19. Ask him/her to develop datamining solutions, so you can get quality data OUT of your EMR.
20. Ask him/her to work with your Chief Medical Officer (CMO), Chief Nursing Officer (CNO), and other leaders to fully implement your EMR and the order sets, protocols, and policies needed to support it.

We recommend keeping your CMIO out of direct sunlight, make sure he/she has a warm place to sleep, and most of all, never feed him/her after midnight.

Sincerely,

The Manufacturer