Clinical Informatics and navigating Healthcare's 'Operating System' (OS)

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

For today's post, I thought I'd write about the intersection of Applied Clinical Informatics (CI) and what I call Healthcare's 'Operating System' (OS) - The daily documents, operations, governance, and decisions that together coordinate healthcare delivery.

To help better understand and navigate Healthcare's 'Operating System', I've broken it down into twelve (12) easy-to-digest mini-topics :

Let's get started : 

1. Healthcare Runs on More Than Software: What Clinical Informatics teaches us about Documents, Operations, Governance, and Clinical Workflow

After years of working in healthcare, medicine, information technology, and Clinical Informatics, I have gradually come to believe that many of healthcare’s hardest problems are not really technology problems - Many are really coordination problems.

And much of that coordination is hidden in something remarkably mundane: documents.

e.g., Policies. Procedures. Guidelines. Protocols. Bylaws. Regulations. Job descriptions. Committee charters. Project plans. Workflow diagrams. Order sets. Clinical decision support. Training materials.

We tend to think of these as separate things, each owned by different departments. After many years in Clinical Informatics, helping to support our users in delivering great patient care - I increasingly think they are all parts of the same system - the 'Operating System'. The challenge is getting that system to conduct.

2. Healthcare has a Document-Driven Operating System

Every healthcare organization has an enormous collection of documents describing what the organization believes should happen : 

• A regulation may establish an obligation.
• A policy may establish an institutional expectation.
• A procedure may describe how that expectation is carried out.
• A workflow may assign the work to particular people at particular moments.
• An EHR may operationalize portions of that workflow.
• Training teaches people how to perform it.
• Measurement tells us whether it actually happened.
• Governance determines who has the authority to decide what happens when these things disagree.

Seen this way, healthcare documents aren't simply paperwork - They are part of the organization's operating system.

And that raises a difficult question: What happens if the 'operating system' doesn't compile?

3. Aspirational vs. Operational Documents

Having spent years troubleshooting workflows, I've come to describe many healthcare policies as either 'aspirational' or 'operational'. 

An aspirational document might say, "Critical results will be communicated promptly to the appropriate provider." This sounds perfectly reasonable, and may even pass a regulatory review.

But try giving that same sentence to an EHR analyst, and asking them to build it. Immediately, questions appear : 

1. Q : Who exactly receives the result?
2. Q : What qualifies as critical?
3. Q : How quickly is "promptly"?
4. Q : Who initiates the communication?
5. Q : What communication methods are permitted?
6. Q : What happens if the first person doesn't respond?
7. Q : Who owns escalation?
8. Q : How is receipt acknowledged?
9. Q : Where is it documented?
10. Q : What happens overnight?
11. Q : What happens for an outpatient who has gone home?

Suddenly, the policy doesn't seem complete - it only appears complete.

An operational document goes further. It translates institutional intent into operationally executable instructions. As I've written about before, I generally reduce that concept to a deceptively simple structure:

TASK = [ WHO ] will/may [ WHAT ] { how } { when } { where } { why }.

The brackets matter - WHO and WHAT usually aren't optional. The other optional dimensions (modifiers) become explicit only whenever they are necessary for clarity, or to execute the work safely and consistently.

This is the basic foundation behind what I call Aspirational-to-Operational, or in short, #BlueprintsBeforeBuild :

Before asking technology to automate a workflow, make sure the organization has actually designed the workflow.

Software should not be asked to resolve ambiguities that organizational governance has not yet resolved.

4. The EHR Is Downstream of Governance

One of the most important lessons I've learned as a CMIO is that an EHR build request is often not really an EHR build request. For example, someone might ask : 

Q : "Can the EHR make us do this?"

Sometimes the answer is technically yes. But often, the more important questions are:

• Q : Who decided that we should do it?
• Q : Who owns the workflow?
• Q : Who has authority to change it?
• Q : Has everyone affected by it agreed to the change?
• Q : Is the policy consistent with the proposed build?
• Q : Who will maintain it after the implementation?

These aren't software questions - they are governance questions. And if governance has not yet resolved this ambiguity, it can flow downstream, where it first reaches Clinical Operations, then Clinical Informatics, and then Information Technology. 

Eventually - if someone asks an analyst to turn an unresolved organizational disagreement into an EHR button, this can be an extraordinarily expensive way to run a healthcare system.

5. Information Technology (IT), Clinical Informatics, Clinical Operations, and Project Management are Different Disciplines

Many healthcare organizations also blur these four functions that need to work together, but are not interchangeable : 

1. Information Technology (IT) manages the infrastructure. Servers. Networks. Devices. Applications. Interfaces. Identity. Security. Availability. IT makes the roads work.
2. Clinical Informatics (CI) manages information, knowledge, workflow, and decision support. It asks how information should move through those roads, what it means, when it should appear, and how it should support human decision-making. CI manages the traffic flows.
3. Clinical Staff and Clinical Operations (ClinOps) manage the actual delivery of care. It determines who is responsible for doing the work, with what resources, under what authority, and according to what operational expectations. ClinOps determines where everyone is trying to go — and why.
4. Healthcare Project Management (PM) coordinates how the organization moves from its current state to its intended future state by managing scope, sequence, timelines, dependencies, resources, risks, communication, milestones, and accountability. PM manages the journey.

So if :

• IT makes the roads work,
• CI manages the traffic flows, and
• ClinOps determines the destination — and why we're going there,

... then Project Management manages the journey.

Here's a helpful graphic, to help remember these four key roles : 

*Special thanks to : Eric Alper, MD (UMass Worcester), Bruce Darrow, MD (Mt. Sinai), Richelle deMayo, MD (CT Children’s), Katy L. Demitruk, MD MAS (Beacon Health), Roy Esaki, MD MS FASA (Queen’s Medical Center), Joel Gordon, MD (UW Health), Jeffrey Hoffman, MD (Nationwide Children’s), Allen Hsiao, MD FAAP FAMIA (Yale), Avniel Klein, MD PhD (Mt. Sinai), Yaa Kumah-Crystal, MD MPH FAMIA (Vanderbilt), Howard P. Levy, MD PhD (Maryland Primary Care), CT Lin, MD FACP FAMIA (Author and former CMIO, UCHealth), Mark Mabus, MD RPh (Parkview Health), C. Becket Mahnke, MD (MultiCare Health), Rebecca Mishuris, MD MPH FAMIA (Mass General Brigham), Brett Moran, MD (Parkland Health), Deepti Pandita, MD FACP FAMIA (UC Irvine), Heidi Twedt, MD FACP FAMIA (U of Wisconsin-Madison), Tara Cortez-Greig, MSN RN (Mass General Brigham/Cooley Dickinson Hospital), Michelle Currie MS RN CPHQ CPHIMS (CurAIte Health), Deborah Russo MSN RN NIBC (UConn Health), James J. McGennis, MPA PMP (Project Mgt Expert, UConn) … and many other Applied Clinical Informatics and Project Management leaders who contributed to developing this graphic.

*Key point : No role can replace the others. An EHR vendor cannot eliminate the need for Clinical Informatics any more than buying asphalt eliminates the need for traffic engineers.

And Clinical Informatics cannot substitute for Clinical Operations. The Clinical Informaticist (CI) can expose an unresolved workflow question, but the organization (ClinOps) still has to answer it.

6. Clinical Informatics Is a Translation Discipline

Over the past 17+ years, I've increasingly come to see Clinical Informatics as living at the boundaries between disciplines. While each group is technically speaking English, their motivations, cultures, and terminology are often very different : 

• Medicine speaks one way,
• Nursing speaks another,
• Operations another,
• Compliance another,
• Quality another,
• Finance another,
• Information Technology another,
• Software vendors another,
• ... and regulators sometimes seem to speak several languages simultaneously.

So very common words such as provider, clinician, protocol, guideline, standing order, referral, transfer, critical result, actionable finding, and even project can mean surprisingly different things, depending on who is speaking.

Clinical Informatics therefore isn't merely about configuring an EHR. A large part of the work is about translation : 

• We translate clinical intent into operational requirements.
• We translate operational requirements into workflows.
• We translate workflows into information requirements.
• We translate information requirements into technology.
• And then we translate what the technology can actually do back into language that clinicians and operational leaders can understand.

That translation layer is not overhead - It is part of the safety architecture.

7. Governance Is the 'Conduction System'

More recently, I've started thinking about healthcare organizations through another helpful metaphor: organizational 'electrophysiology'.

Huh? Stay with me : A healthcare organization resembles a heart more than we might realize.

• There are many capable cells.
• Many can generate activity independently.
• But truly effective performance requires coordinated conduction.

Similarly, healthy organizations have recognizable pathways through which authority, information, decisions, and work travel.

• Like a sinoatrial (SA) node, a Senior Leadership team provides the strategic impulses.
• Governance creates the conduction pathways.
• Clinical Operations produces the coordinated actions.
• Clinical Informatics helps translate and synchronize information across those pathways.
• Information Technology provides the infrastructure through which much of that information travels.

When those pathways work, thousands of people can act as a coordinated organization. When they don't, the organization begins behaving something like a heart with an arrhythmia :

• Committees fire independently,
• Departments create competing priorities,
• Projects originate everywhere,
• Policies contradict workflows,
• Technology teams receive conflicting instructions, and
• Executives become escalation pathways for routine operational decisions.

In this scenario, an organization may be extremely busy while accomplishing less than anticipated.

8. Organizational 'Ejection Fraction'

This led me to another analogy I've found useful: Organizational 'Ejection Fraction'.

Uncoordinated, a heart can consume enormous metabolic energy without producing effective forward flow. Analogously, healthcare organizations can do the same thing.

Imagine an organization putting 100 units of human effort into meetings, emails, projects, committees, escalations, presentations, and technology builds. Q : How much useful organizational work actually emerges?

A : If only 30 units become coordinated action, the organization has an 'organizational ejection fraction' of roughly 30%. The remaining energy hasn't disappeared - It has been consumed by friction : 

• Duplicate meetings.
• Competing priorities.
• Unclear authority.
• Policy ambiguity.
• Rework.
• Escalations.
• Failed handoffs.
• Poorly defined projects.
• Technology built before workflow was designed.

So the objective of good governance isn't to create more governance - it is to reduce organizational impedance. In short : Good governance should increase forward flow.

9. Why Organizations Become Surprisingly Efficient During Crises

After speaking with a number of Clinical Informatics colleagues over the years, several of them have described a very interesting phenomenon that sometimes happens in healthcare : 

Organizations that normally struggle to make a decision in six months can sometimes reorganize themselves in six hours during a crisis. 

Q : Why?

Because crises temporarily simplify governance : 

• Priorities become obvious.
• Authority becomes explicit.
• Competing initiatives disappear.
• Decision pathways shorten.
• One leader or command structure becomes the dominant pacemaker.

So for the cardiologists in my audience : In electrophysiologic terms, a crisis can behave almost like 'organizational adenosine' - the usual competing conduction pathways are interrupted long enough for a coherent rhythm to emerge.

*Note : The lesson shouldn't be that organizations need crises. Instead : 

• The lesson is that the organization was always capable of moving that efficiently, but...
• ... the crisis merely removed the routine organizational resistance that normally prevents it.

So the challenge for Healthcare leadership, in developing governance, is learning how to reproduce some of that clarity without requiring an emergency.

10. Documents, Governance, Operations, Informatics, and Technology Form a Chain

Based on these impressions, I've started thinking about healthcare delivery as a connected chain:

Regulation → Governance → Policy → Operations → Workflow → Informatics → Technology → Delivery → Measurement → Learning

Every arrow matters : 

• A failure upstream eventually becomes a problem downstream.
• Ambiguous regulation requires interpretation.
• Ambiguous governance produces conflicting policy.
• Ambiguous policy produces inconsistent operations.
• Inconsistent operations produce undefined workflows.
• Undefined workflows produce bad requirements.
• Bad requirements produce bad technology.
• And without adequate vigilance, bad technology can eventually reach a healthcare worker or a patient.

By the time the problem appears on someone's computer screen, the root cause may have occurred several organizational layers earlier. That is why endlessly "fixing the EHR" rarely fixes the underlying organization.

11. #BlueprintsBeforeBuild

Healthcare is generally good at buying technology - We are less consistent at designing the 'operating systems' into which that technology is placed. Before building something, we should be able to answer:

1. Q : Who owns this?
2. Q : Who has authority to implement this, on behalf of Clinical Leadership?
3. Q : Who routinely performs the work?
4. Q : What exactly are they expected to do?
5. Q : Under what circumstances?
6. Q : Using what information?
7. Q : What happens when the normal pathway fails?
8. Q : Where is the authoritative source describing this workflow?
9. Q : How will we know whether it worked?

Only then should we ask:

Q: What should the software do?

That is the essence of #BlueprintsBeforeBuild.

12. The Larger Lesson

Clinical Informatics is sometimes described as the intersection of people, process, and technology. While I very much agree with this, I do think this description may be a little incomplete. The field also sits at the intersection of:

authority, language, information, workflow, operations, technology, and human behavior.

The EHR is simply where many of those forces become visible : 

• When an EHR workflow is confusing, the problem may be software.
• But it may also be an unclear policy.
• Or undefined ownership.
• Or conflicting governance.
• Or inconsistent terminology.
• Or an operational process that nobody ever actually designed.

Clinical Informatics gives us a remarkable vantage point from which to see these failures because we live where organizational intentions collide with operational reality.

And perhaps that is one of the most important roles of the Clinical Informaticist:

• To make the invisible architecture of healthcare visible.
• To turn aspirations into specifications.
• To turn specifications into workflows.
• To make workflows understandable before they become software.
• To identify organizational 'arrhythmias' before they become patient-safety events.

And to help healthcare organizations convert more of their enormous human effort into coordinated forward flow.

Because ultimately, the end goal isn't : 

• better documentation, or
• better governance, or 
• better technology,

The goal is better delivery. Everything else is infrastructure.

----------------------------
For all of my talented Clinical Informatics colleagues out there, I hope this is a helpful summary that you can use for group discussion. Please feel free to adapt and share, or provide feedback below.

----------------------------
Remember, this blog is for education and discussion purposes only - Your mileage may vary.

Have any helpful Clinical Informatics insights you'd like to share? Have any experiences with workflows, governance, policies, or the 'Operating System' of Healthcare? Please feel free to share in the comments section below!

The Well-Tempered #HealthIT Department Index

Hi fellow CMIOs, CNIOs, workflow gurus, and other Applied Clinical Informatics friends,

I'm writing today to share an interesting design I developed to help HealthIT departments to better organize, understand each other, and share information in a more organized way.

Animated GIF for easy sharing

Coming up with an organizational index like this requires a lot of thought about :

• Q1 : What does it take to run a standard HealthIT department (for both large Academic Medical Centers that often conduct research/clinical trials, and non-Academic, community health centers)?
• Q2 : Who are the common team members (and teams), and how are they organized?
• Q3 : How do they work together?
• Q4 : Who do they serve, and how?
• Q5 : Is the departmental model scalable/expandable, as an organization grows (or partners with other organizations)?

In short - Many #HealthIT departments have a group demand for a lot of information sharing, but there's not a lot of consensus on exactly how to do this. While I've seen different attempts at 'organizing this closet', many of the designs I've seen are either : 

• [   ] too coarse (everything in one disorganized, central file space, with people using alpha-search and AI to try to find files)
• [   ] too granular (everything in filed in many separate, distributed folders, sometimes down to the individual user, with people using alpha-search and AI to try to find files)

The challenge is to find the 'goldilocks' folder structure, just intuitive enough that everyone can find their way around, and yet flexible enough to scale as an organization grows. Neither too many folders, nor too few, are desirable.

*Interesting side-note : For those of you who might be classical music fans - This indexing challenge is somewhat reminiscent of Bach's Well-Tempered Clavier, which was his answer to the 1700s question of 'Exactly how many notes do we need in a scale?' For more on this fascinating challenge, and how Bach solved it - and its long-standing impact on modern music - see this YouTube video : https://youtu.be/NCMrHkMCeXk 

So after a lot of discussion, review, and validation with other HealthIT and other Clinical Informatics leaders, I think I've come up with a fairly reasonable design for organizing all of this that is fairly simple, organized, intuitive, and scalable as an organization grows.

It's a simple hub-and-spoke model - One hub, and nine spokes. Remember - This is just a proposed model, and your mileage may vary. Let's look at them in more detail, for your consideration and feedback : 

A. THE HUB : Your #HealthIT Department (Leadership) Homepage

This is the primary welcome page for your staff to arrive in your departmental development space, and gives everyone one-step, easy-access to common departmental materials like :

• Important news and departmental announcements
• IT Portfolio
• IT Roadmaps (including Administrative, Clinical, Research, and Academic)
• IT Policies, Standards, Templates, Forms, and Terminology (this also includes departmental file naming conventions)
• AI Strategy, Governance Committees, and Oversight
• IT Intake and Procurement
• IT Org Charts

A1. SPOKE 1 : Your Administrative IT Application Dev/Support Homepage

This is where your Administrative IT Application team will support common Administrative systems, like : 

• Email Server
• Web Services (includes Intranet and Extranet services)
• Safety / Security Systems
• Human Resources (Timekeeping, Payroll, etc.)
• Official Document Management (e.g. Policies, Bylaws, Guidelines, Protocols, etc.)
• Finance Systems
• Revenue Cycle
• Billing Systems
• Provider Credentialing / Med Staff Office systems
• Other Credentialing / Human Resources
• Contracting
• Facilities Management
• Supply Chain / Procurement
• ... and other Administrative Systems

A2. SPOKE 2 : Your Clinical IT Application Dev/Support Homepage

This is an important page, and based on the informal, de-facto NIST/HITRUST-supported criteria for Academic Medical Centers, this is likely to contain support for : 

• Your Tier 0 systems (downtime tolerance=minutes), including your central Bed Monitoring, Telemetry, Secure Chat, Core EHR production, Pharmacy Systems (order verification, dispensing), Radiology PACS/Imaging Views, Laboratory Systems (e.g. critical analyzers), ADT/Identity/Registration services, and Clinical Authentication (SSO, badge-tap)
• Your Tier 1 systems (downtime tolerance=few hours), including your clinical documentation modules, OR scheduling systems, ED tracking boards, Clinical Decision Support engines, routine (non-STAT) results reporting, and Interface engines supporting clinical data flow
• Your Tier 2 systems (downtime tolerance = few days), including your Revenue cycle systems, billing and claims, Enterprise Resource Planning / Supply Chain, non-clinical scheduling, Data warehouses
• Your Primary EHR and common support teams, including core and 3rd party Pharmacy, Lab, Radiology, and other specialty systems for Inpatient, ED, Perioperative, Ambulatory Procedural Suites, Ambulatory Clinics, and Homecare functions
• Your 3rd Party ('bolt on') Applications in your various clinical areas, and the administrators / developers for each one
• Your Applied Clinical Informatics / Workflow Analyst Development Spaces (e.g. for your Ordering/CPOE projects, Workflow Projects, and Clinical Decision Support (CDS) project analyses)

Carefully planning this Clinical IT page, with cross-referencing hyperlinks, can turn this page from a file storage area into a knowledge base and tool of learning and understanding. 

A3 : SPOKE3 : Your Research IT Application Dev/Support Homepage

If you are an Academic Medical Center that does clinical research (clinical trials), this is the page for your team members who support your Research IT applications, including :

• Your Core Research Labs/Areas
• Your Independent Review Board systems
• Your Clinical Trials Management (CTMS) system(s)
• Your Research Compliance
• Your Research Committees and Governance
• Your High-Performance Computing (if available)
• Your Research Analytics Systems
• Your Data Science / Translational Science Systems
• ... and other Research systems

A4 : SPOKE4 : Your Academic IT Application Dev/Support Homepage

If you are an Academic Medical Center with an academic mission, this is the page for your Academic IT systems including : 

• Academic Administration Systems
• Academic Registration Systems
• Academic Scheduling Systems
• Academic Grading/Scoring Systems
• Learning / Simulation Systems
• Graduate Medical/Dental/Nursing/Pharmacy Education
• Continuing Medical/Dental/Nursing/Pharmacy Education
• Undergraduate Medical/Dental/Nursing/Pharmacy Education
• ... and other Academic IT systems

A5 : SPOKE5 : Your IT Project Management Office (PMO) Homepage

Most HealthIT departments of sufficient size have a formal Project Management Office (PMO). If you have a PMO, you will need a page for PMO team members (and the many people who interact with the PMO and active projects), so this page could include : 

• Project Intake
• Prioritization Rubrice
• Project Governance
• Project Utilization Dashboards
• Project Templates
• Project Development Folders/Spaces
• Other Project Management Office (PMO) Tools

A6 : SPOKE6 : Your Enterprise Technology (Infrastructure) Dev/Support Homepage

This is where your Enterprise Technology (Infrastructure) Development and Support teams could easily find folders and supporting materials for : 

• Platform & Middleware Layer Applications (e.g. Windows/OS, Citrix, Virtualization/VM Ware, Interface engines, batch jobs, schedulers, and data warehousing)
• Identity and Security Layer Applications (e.g. Active Directory, SSO/MFA, Certificate services, etc.)
• Network and Firewall Layer Applications (e.g. Wireless, switches, routers, VPN, firewall, etc.)
• Physical Layer Applications (e.g. HVAC, cooling systems, fire suppression, telecom, elevators, electric grid, backup generators)

A7 : SPOKE7 : Your Business Intelligence, Reporting, and Analytics Homepage

This is where your Business Intelligence, Reporting, and Analytics team members could support your : 

• Administrative Reporting and Analytics - E.g. for HR, Legal, Finance, Compliance, or other Administrative purposes
• Clinical Reporting and Analytics - E.g. for Clinical, Quality, Operational, Scheduling, or Billing/Operational purposes
• Research Reporting and Analytics - E.g. for Research purposes, Clinical Trials, IRB support, Research Compliance support, etc.
• Academic Reporting and Analytics - E.g. for Academic/Educational purposes, Academic research projects, etc. 

A8 : SPOKE8 : Your IT Security and Privacy Team Dev/Support Homepage

This is where your IT Security Team could find and develop important IT security materials including : 

• Role-Based Security Templates
• Incident Reporting
• Account and Access Security (includes Onboarding/Offboarding and Role Changes)
• Security, Privacy, and Data Protection Policies
• Governance Committees and Leadership
• Multifactor Authentication (MFA) support
• Single Signon (SSO) support
• Security Training and Awareness Materials
• Other IT Security applications and files

A9 : SPOKE9 : Your IT Customer Service & Support (Service Desk)

This is where your IT Customer Service and Support (IT Service Desk) Team members (and others) could easily access helpful materials like : 

• IT Support Ticketing Systems
• Triage protocols
• Self-Service / Quick fixes
• Escalation Pathways
• Major Incident Board
• Status Board
• Outages / Alerts
• Known Issues
• Requests & Lifecycle Services
• Lost Equipment Reporting
• Data breach Reporting systems
• Planned Downtime Policies
• Unplanned Downtime Policies

SCALING / GROWTH : 
Assuming your team chooses to adopt this model for your organization, you could easily expand/scale this model to additional partner organizations, through a simple set of hyperlinks from these pages, e.g. : 

• [ Organization A : Project Management Page ] 
• [ Organization B : Project Management Page ] 
• [ Organization C : Project Management Page ] 

In this way, each organization would have a clean page for their own unique needs, while keeping all of the Project Management pages closely linked and aligned in expectations. (This would allow you to gradually continue to align, as organizations mature.)

SOME FINAL THOUGHTS : 

This is just a sample model, that I thought I'd share for friendly review, discussion, and feedback. If nothing else, I hope this has been a fun and helpful journey navigating through the most common functions, teams, and roles of #HealthIT, and welcome feedback or comments from others who have already explored this journey.

Remember : This blog is for academic and educational discussions only - Your mileage may vary. Have any feedback or suggestions? Leave in the comments section below!

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!