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! 

Why Healthcare needs Clinical Architects

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

Some of you might already be familiar with #BlueprintsBeforeBuild, the hashtag I started several years ago (on X/Twitter, LinkedIn, and elsewhere) to help create awareness of the need for good workflow design in healthcare technology. 

You might also be aware of the value of having an Applied Clinical Informatics ('Clinical Architecture') team in Healthcare, to assist with things like : 

1. Project Intake or Procurements that require additional support or workflow evaluations, to help ensure the technology does not already exist, and to help ensure proper scoping, budgeting, stakeholder identification, resource allocation, necessary safety, compliance, and regulatory reviews, and expected outcomes.
2. Special Event Workflow Planning (e.g. Planned upgrades and maintenance, unplanned downtimes, project go-lives, etc.)
3. Complex IT Tickets that require workflow updates or modifications (which often span multiple areas with multiple stakeholders)
4. Complex Projects that require clinical translation, terminology work, stakeholder alignment, or other workflow updates/modifications
5. Ongoing Maintenance of existing configuration / workflows to meet CMS/TJC regulations, that require continuous staff engagement with multiple stakeholders across different areas and specialties. 
6. Helping to ensure clinical workflows are aligned with the Clinical, Administrative, HIM, Regulatory/Compliance, coding/billing, and revenue capture needs of the organization. 

So while my last post helped to ask and answer the question, "Where is the Clinical Informaticist?", this month's post is related to my support of an easy way to make Applied Clinical Informatics more familiar and tangible for newcomers - Instead of "Clinical Informatics", consider using the synonyms "Clinical Architect" and "Clinical Architecture" :

 

While some organizations have clinical staff (MDs, RNs, APRNs, PAs, Pharmacists, Lab/Radiology staff, and others) who are trained to configure computers, other healthcare administrators might question the reasons for paying a clinical team member to do this sort of configuration (building) : 

Q : "Why should we pay a doctor (or RN, APP, or other clinical role) to do this?"

In addition to the six deliverables mentioned above, there are other good reasons to pay clinical staff to be involved in your EMR go-live, configuration, and ongoing maintenance, including :

• Improved user satisfaction and workflow design (See this recent AMA article for a success story from TSPMG on the benefits of improved user engagement!)
• Improved upkeep of technology (to reflect continuously-changing medical literature and other clinical, regulatory, and billing standards)
• Improved utilization (ROI) and stewardship of your technology
• Improved quality metrics and revenue capture
• Improved patient care
• Improved patient satisfaction

... where clinical staff play an essential role in experiencing and understanding their workflows, translating their workflows, and maintaining their workflows. The questions then become : 

• Q : "Do we need clinical staff to build configurations?" ('Clinical Builder')
• Q : "Or do we need them to architect clinical workflows?" ('Clinical Architect')

While many clinical staff begin their HealthIT journeys focused on build - I would argue that there is a value in focusing their efforts on clinical architecture, rather than construction. Here's why.

Effective, predictable change management generally begins with a ten step process :

Generally speaking, these ten steps include : 

1. Documenting and understanding the change.
2. Analyzing, evaluating, designing, and scoping the change.
3. Prioritizing and approving the change project.
4. Building the project team (including stakeholders, deliverables, and timelines).
5. Designing blueprints for all EMR/Non-EMR deliverables (for discussions, tabletop exercises, edits, and to secure necessary buy-in and approvals)
6. Building the change (Analyst)
7. Testing and approving the change (future-state workflow)
8. Communicating and educating (training) the change
9. Implementing the change
10. Monitoring and supporting the change

After reviewing these steps, the questions then become : 

• Who supports each of these steps?
• Do your IT Analysts typically support step #6?
• If so, are your clinical staff then more useful in step #6, or in steps #2 and #5?
• Could any analyst time be saved in #6 with more informatics time spent in #2 and #5?

This may seem somewhat paradoxical at first, since many clinical staff initially gravitate towards building when they first get involved in healthcare technology. After all, it seems like a good way to get involved, learn about data structures, and get some control over the systems they use to deliver care to patients. 

But on closer inspection, I believe there's real value in focusing your clinical staff on architecture, rather than construction (build) : 

From Wikipedia : Architecture is the art and technique of designing and building, as distinguished from the skills associated with construction. And what connects architecture to construction is blueprints. (Note : For more about architecture, please also see this helpful Brittanica article.)

So for most clinical staff first getting involved in HealthIT, having some experiences with construction is very helpful. Unless they have some kind of a background in computer science, it's still very helpful (foundational) to learn about data structures, relational databases, indexing, and coding. 

But once they have this foundational understanding, I personally think their bigger value comes from using their clinical expertise to architect workflows using blueprints, rather than building (configuring) workflows. Here's why : The value of blueprints in construction is typically underestimated :

• Blueprints allow you to quickly mock up deliverables (e.g. the EMR and non-EMR deliverables that work together to support your desired workflow)
• They let you share your mockups with other clinical staff, to discuss, review, create tabletop exercises, make edits, and secure necessary buy-in and formal approvals.
• They let you then share your approved blueprints with your IT analysts (who can then quickly create the electronic deliverables in your EMR, e.g. orders, order sets, clinical documentation, alerts, charges, etc.)
• They let you share your approved mockups with other Clinical Leaders (who can then help create the non-EMR deliverables, such as policies, guidelines, protocols, schedules, training, budgets, etc.)
• Finally, blueprints can also help save analyst time while synchronizing your electronic (EMR) deliverables with your paper deliverables (downtime forms).

How can blueprints help save analyst time, while synchronizing your electronic and paper deliverables (for planned EMR maintenance / unplanned EMR downtimes)? They can do this because blueprints help to create clear understanding and discussions, and allow clear edits and revisions, that are necessary before you can secure the necessary buy-in and final approvals - Not just from your clinical staff, but also from your Legal/Compliance/Regulatory staff, Pharmacy staff, Nursing staff, Radiology staff, Laboratory staff, HIM staff, Billing/Coding staff, Clinical Leadership, IT leadership, etc. 

Having that level of clarity, understanding, and buy-in is very difficult to achieve after something has been built. (This is a common reason for IT Analyst complaints of having to build and re-build something before it's right.) So why not put your Clinical Architects (Clinical Informaticists) to work on blueprints, rather than build?

And so once your IT analysts are working on the electronic (EMR) deliverables, blueprints are then also very easy to convert to paper downtime forms :

So that process for creating synchronized EMR deliverables (from an IT Analyst) and paper downtime forms (from a Clinical Architect / Clinical Informaticist) can then look like this : 

How to use blueprints to create matching paper and electronic tools : 

1. Clinical Architect (Clinical Informaticist) will study and design the desired (future-state) workflow. 
2. Clinical Architect (Clinical Informaticist) will use templates to quickly mock-up blueprints for all deliverables. 
3. Clinical Architect (Clinical Informaticist) will use blueprints to review and share with staff and other stakeholders, conduct tabletop exercises, lead clear discussions, make necessary edits/changes based on feedback, and secure the necessary buy-in and approvals.
4. Clinical Architect (Clinical Informaticist) will share and discuss approved blueprints with IT Analyst, for building and testing of electronic deliverables.
5. Clinical Architect (Clinical Informaticist) will convert blueprints to paper downtime forms.

So to summarize, some key take-home points from today's discussion :

• There is real value in having (some) clinical staff engaged in the development and ongoing maintenance of your EMR and downtime processes (e.g. improved outcomes, improved user and patient satisfaction, improved quality metrics, improved revenue capture, etc.) 
• Clinical architecture (Clinical Informatics) is the art and technique of designing and building clinical workflows, a specialty distinct from (but intrinsically related to) IT Analysts (who commonly focus their primary efforts on construction).
• Clinical staff commonly begin their HealthIT career journey focused on building in an EMR, but their value can increase when they focus their efforts on clinical architecture (Clinical Informatics) and blueprint development.
• Blueprints can help save project and IT analyst time by creating the necessary discussions, understanding, buy-in, and approvals before beginning construction.
• Blueprints can also help synchronize your electronic deliverables with your paper downtime forms (by making it easy to create downtime forms with the same appearance, format, and cadence as your electronic deliverables).
• An easy way to improve clinical workflow design, improve outcomes and user satisfaction, save time, create clarity and understanding, and develop smooth downtime processes is to develop a Clinical Informatics (Clinical Architecture) team, and remember the hashtag #BlueprintsBeforeBuild!

For many of you, this discussion is probably just a refresher. For others, I hope this was a helpful discussion, for you and/or your clinical informatics teams. Please let me know your experiences, and feel free to leave comments and feedback in the comments section below!

Disclaimer : Remember, this blog is for educational, discussion, and information-sharing purposes only - As always, your mileage may vary! Remember to always have your clinical leadership, IT, and legal/compliance teams review any changes to processes before you initiate them. Have any related experiences, or other suggestions for improving clinical workflow design? Leave your comments and feedback below!