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!

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!

Advice from a Wise Business Leader

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

A brief pause from Applied Clinical Informatics, just for a moment. 

Today's post is related to some helpful business ethics advice I once received from a wise and successful businessman my mother used to work for. His name was James ('Jim') Everett Robison (11/22/1915 - 2/21/1998), and he was a very successful businessman and Harvard Business School graduate who, in addition to having a wonderful and loving family, also counted Roy Little and Thomas J. Watson, Jr. as some of his business associates and friends.

(L) James E. Robison as an Air Force pilot circa 1940s, and (R) as a successful business leader circa 1990s.

A retired and decorated WWII Air Force Major (who flew 63 completed missions, 402 combat hours, 26 squadron leads, 7 group leads, and 1 wing lead!), Jim Robison lived and breathed integrity.

Growing up, I would run into Mr. Robison occasionally, while my mother was working for him in Armonk, NY back in the 1980s and 1990s. During one of my visits to my mother's workplace, he shared a message with me - one that he apparently also shared with many other people - about the importance of honesty, integrity, and ethics in business.

His message was once captured beautifully by his good friend Charles Osgood, who shared it in his November 24th, 1992 Osgood File message. 

The message is still so important and relevant, that I think it bears repeating today. Transcribed from an old cassette tape I found in my attic, here it is : 

TRANSCRIPT :

Charles Osgood

CBS 880 AM Radio 11-24-1992

[ Start of Transcript ]

The Osgood File, sponsored in part by ______ Heating and Cooling. I'm Charles Osgood.

Last night at the University Club in New York, I attended a reunion dinner of sixty (60) people who used to work for the same company my late father did. There were books of pictures, and in some of them I could hardly recognize dad because he was so much younger then, than I am now. It made me feel like Michael J. Fox in "Back to the Future".

And amongst the memorabilia I found something that impressed me so much, I wanted to share it with you, which I will do, in a moment. Stand by.

My father was in the textile business. His boss, at a company called Indianhead Mills, was a dynamic young man by the name of Jim Robison. Dad thought the world of Jim, not only because he was so smart and so successful, but also because he was such a straight shooter. Robison never wanted to outdo or get the better of anybody in a business deal. If both parties didn't benefit from the deal, he didn't want to do it.

My dad died several years ago, but last night I was invited to a reunion of Indianhead people, some of them I hadn't seen since I was a kid. Jim Robison was there, retired now and no longer a young man, but still sharp as ever. And looking through some materials they had there, I came on a company policy statement that he had issued 40 years ago. And I took a copy of it because I wanted to share it with you this morning. Here's what it said :

"There is one basic policy, to which there will never be an exception made by anyone, anywhere, in any activity owned and operated by Indianhead. That policy is as follows," Jim Robinson wrote. "Play it straight, whether in contact with the public, stockholders, customers, suppliers, employees, or any other individuals or groups. The only right way to deal with people is forthrightly and honestly. If any mistakes are made, admit them and correct them. Our commitments will be honored, and we have a right to expect the same performance from those people with whom we do business.

This is fundamental. We will not welch, weasel, chisel, or cheat. We will not be a party to any untruths, half-truths, or unfair distortions. Life is too short.

It is perfectly possible to make a decent living without any compromise with integrity."

I think I'm going to frame that and put it on the wall.

The Osgood File, Charles Osgood on the CBS Radio Network.

[ End of Transcript ]

I agree with Charles Osgood - I think I'm going to frame that and put it on the wall.

I hope this timeless message inspires you too!

Remember, this blog is for informational and educational purposes only - Your mileage may vary! Have any experience with studying business ethics? Please feel free to share in the comments below!

Applied Clinical Informatics Progress Bar Video

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

I recently put together a quick animation, help tell the story of Applied Clinical Informatics in a short (2 minute 38 second) YouTube video.

There's not much to say, other than it frames one potential journey - from beginning to end - and the progress that eventually leads to improved engagement, improved usability, improved return-on-investment, and most importantly - improved patient care.  

YouTube Link : https://youtu.be/mFL6WkPaog4

At the end, the bar suddenly returns to the very beginning - Letting the viewer consider their own journey. 

Feel free to share with anyone who's looking to better understand the Applied Clinical Informatics journey, and the many benefits it (and #BlueprintsBeforeBuild) can bring. 

Remember - This blog is for academic and discussion purposes only - Your mileage may vary!

Have any experience from your own journey that you would like to share? Feel free to leave in the comments section below!

Getting from A to B : Project Management for Clinical Leaders

 Hi fellow CMIOs, CNIOs, #HealthIT, and #Informatics leaders and friends,

Change is important. As a clinical leader, you'll want to know how to make workflow changes, either to help fix a workflow that's not ideal, update a workflow that needs updating, or build a new workflow. (As long as there are new journal articles and conferences, there will be necessary updates to clinical practice to stay current.)

So this week, I thought I'd write about a topic that can help a clinical leader to feel comfortable with making changes in their area: 

"How to get from Point A to Point B"

I once alluded to a problem with making changes back in 2016, when I blogged about the Red Sneaker Problem - And How To Fix It. To help avoid frustration for you and your team, it's helpful to understand 'How does anything change?'. Without understanding the change process, it can be hard to make change. 

Although clinical leaders often need to focus primarily on clinical services, functions, and expertise - it's still helpful to know the basics about two important things, related to 'how things get done' : 

1. Project Intake / Scoping - Helps you secure necessary people, time, and resources before you start a change project.
2. Project Management - Helps you effectively use those people, time, and resources to get things done (accomplish the change)

Without understanding these two steps, it can be very hard to accomplish much change. And without regular, smooth, and predictable changes, clinical leadership can seem more daunting than it needs to be. 

So as a brief introduction for new clinical leaders, let's review these two items in a little more detail. Borrowing some slides from a recent presentation I did for a group of clinical leaders, I present some high-level overview below. 

1. PROJECT INTAKE / SCOPING - 

Making change is work. It takes people, time, and resources, to move your CURRENT state (Point A) to your desired FUTURE state (Point B). 

Ideally, to make sure you have the 'gas' needed to drive your 'car' to where you want it to go, you'll first need to understand the scope ('size') of your project. Conceptually, think of this as collectively driving your car (with your team inside it!) from :

• Your CURRENT state (Point A)
• Your desired FUTURE state (Point B)

This is why I always advise people to formally map the current and future states. The distance between these two points is what will determine the scope (size) of your project,  and the work effort (and resources) needed to accomplish your goal.

• If you have the time, people, and resources necessary to get from Point A to Point B - Great! 
• If you don't... Then you may feel frustrated.

So to make sure you have a thorough, well-documented analysis that you can share with your project team - it's very helpful to formally document, in a folder, your CURRENT state, and also formally design your ideal FUTURE state, one that is formally signed off by the clinical leaders who oversee the clinical staff who will live in this new future-state workflow. 

People sometimes ask me : "Do I need to do this much for every change I want to make?" My advice : You only need to apply as much rigor as you need to get the change accomplished. E.g. : 

• For small changes (e.g. making some small changes to a documentation template) --> Usually, less rigor is required
• For large changes (e.g. implementing electronic med reconciliation at all transitions of care) --> Much more rigor is required

This exercise will not only help you scope your project, and identify the people, time, and resources you will need to secure - It will also help you formally plan a project, estimate the return on investment (ROI), and secure the necessary approvals before beginning your project. 

2. CLINICAL PROJECT MANAGEMENT

Once you have secured the necessary people, time, and resources, and have the approvals of your leadership to move forward - It's helpful to identify a formal, trained, and experienced project manager to plan, orchestrate, and lead your project. For a high-level overview, you can see the Wikipedia piece : https://en.wikipedia.org/wiki/Project_management 

For planning purposes, many experienced project managers might develop a Gantt Chart ( see https://en.wikipedia.org/wiki/Gantt_chart ), a sort of ordered series of steps, with time estimates and dependencies, that will be needed to finish the project and achieve the desired outcome. Similar, but also helpful is a Responsibility Assignment Matrix, sometimes called a RACI Chart. 

Experienced clinical leaders, especially those who have worked with good project managers, can often help a project by anticipating steps and helping to answer questions before they arise. While there are different types of project management (from the more traditional waterfall model, to newer agile methodologies), I've stripped down some bare essentials that are helpful to think about before starting any clinical update or improvement project : 

These are the ten steps (above) that I commonly plan and follow for clinical projects, where the rigors of step two (2) above are often necessary to help adequately scope and plan clinical projects, and help ensure that there are no unanticipated surprises later in the project. Note: Clinical Informatics professionals often work in steps 2, 4, 5, 6, and 9 above, working closely with end-users, analysts, educators, and project managers.

As a clinical leader, you will want to help champion change and updated practices. While there is much more to be said about project intake, scoping, planning, and execution, I hope this little introduction will help my friends in clinical leadership see the value of good project managers, and good project planning, and the role they play in getting things done.

Remember, this blog is for educational purposes only - Your mileage may vary. Always ask your local Project Management and Clinical Informatics professionals for guidance, and work closely with your clinical leadership to review, prioritize, and approve your projects before initiating any changes.

Have any stories to share about clinical leadership in supporting clinical projects? Have any tips or tricks to share from your own clinical project management experiences? Feel free to leave them in the comments section below!