Where's the Clinical Informaticist?

Hello fellow CMIOs, CNIOs, and other Applied Clinical Informatics friends,

This month I'd share some cool discoveries I've made with some friends recently, in a helpful blog post about finding the Clinical Informaticist(s) in your organization, and/or identifying the need for them.

One of the common challenges of Applied Clinical Informatics is that Informaticists can sometimes be hard to find. Typically due to a number Human Resources (HR) and other industry issues, they can sometimes be hidden behind : 

• FALSE NEGATIVES - E.g. People who actually do Clinical Informatics work, but aren't necessarily titled "Clinical Informaticist" in their job title, or aren't recognized as doing Clinical Informatics work at all.
• FALSE POSITIVES - E.g. People who are called "Clinical Informaticist", when they don't necessary do the work that might commonly fall under the domain of the Clinical Informaticist (or they only do a specialty branch on the larger 'tree' of Applied Clinical Informatics - See below.)

While some have tried to tackle these HR challenges, concrete job descriptions are hard to find since there is such a wide variation of practice, in the general 'tree of Informatics' - which spans a number of disciplines related to both data storage ('data in') and data retrieval ('data out') functions : 

If your search for a Clinical Informaticist turns up negative, you will probably need to establish the need to hire one (or more) to help with your clinical workflow analysis and development. Historically, there have been two common approaches to doing this in #Healthcare - the 'Clinical Choir' approach, and the 'Executive/Financial' Approach: 

Each of these historic approaches come with some pros and cons : 

1. The 'Clinical Choir' Approach - Where the Clinical Staff recognizes the need for workflow updates and redesign, and collectively asks for Applied Clinical Informatics resources. PROS : Support from clinical end-users can be very helpful to support the allocation of FTE(s) for Clinical Informatics. CONS : Difficult to execute. Most clinical end-users aren't familiar with the potential role of Applied Clinical Informatics in their day-to-day workflows, so it's not easy to get them to ask for it by name. 
2. The Executive / Financial Approach - Where the Executive / Finance teams recognize the need for improved Return on Investment (ROI) and overall improved stewardship of technology investments, and so they collectively ask for Applied Clinical Informatics resources. PROS : Support from Executives and Finance officers can also be helpful to support the allocation of FTE(s) for Clinical informatics. CONS : Most ROI from workflow design and improvement falls under the category of 'soft ROI' which could easily be attributed to other departments, or it falls into the category of cost reduction rather than revenue improvements. (Both will help your organization, but one is easier-to-identify.) So putting a hard number to ROI or cost reduction that stands up to scrutiny will require some real pre-planning before you execute your improvement projects.

So for today, I'd like to share a new approach that I recently discovered, when I worked with some of my trusted Project management and Compliance colleagues (Jim McGennis and Elle Box) to combine my 10-step change management recipe with a Responsibility Assignment (RACI) Matrix :

First, a brief reminder that my recommended ten steps for clinical change management (originally published back in 2018) helps to create consistent outcomes through the thoughtful analysis, scoping, development, and planning of workflow changes (both big and small) :

After combining these ten change steps (above) with a Responsibility Assignment (RACI) Matrix (typically used by experienced Project Managers for assigning responsibility for various tasks), new discoveries were made and additional clarity was achieved. (Note : If you're new to Responsibility Assignment / RACI matrices, please see this Wikipedia article for a helpful introduction. And special thanks to PM guru Jim McGennis, for introducing me to this powerful tool.)

The basic premise of a RACI matrix is that you create a grid (spreadsheet) of roles versus steps, and then assign these four categories in each step : 

• (R)ESPONSIBLE (also recommender) - The one (or more) person(s) who are responsible to complete the task.
• (A)CCOUNTABLE (also approver or final approving authority) - Who is ultimately answerable for the correct and thorough completion of the deliverable or task, who also ensures the prerequisites of the task are met, and delegates the work to those responsible.
• (C)ONSULTED (sometimes consultant or counsel) - Those whose opinions are sought, typically subject matter experts (SMEs), and with whom there is two-way communication
• (I)NFORMED (sometimes informee) - Those who are kept up-to-date on progress, often only on completion of the task or deliverable, and with whom there is just one-way communication.

Putting my 2018 clinical change management recipe together with the RACI matrix has been remarkably helpful and enlightening. And with some help from Compliance colleages (thanks to Compliance guru Elle Box for her help reviewing and refining the descriptions), the first thing I began to notice was the number of roles that participate in one or more steps of change management : 

Roles that participate in one or more steps of clinical change management

 

Roles that participate in one or more steps of clinical change management

... as well as the details of exactly who is (R)esponsible, (A)ccountable, (C)onsulted, and (I)nformed at each step. (*Note : In the slide above, you'll notice that the Applied Clinical Informaticist already has a different set of roles and responsibilities than the Clinical IT Analysts. More to come on this shortly...)

When we look at the first phase of the change recipe (documentation of request and expectations, or intake) it's easy to see who has primary and secondary (R)esponsibility - Both the clinical end-user and the official requestor - their supervisor, director, chair, or chief - who needs to help support the request : 

First phase of change : Documentation of Request and Expectations ('Intake')

First phase of change : Documentation of Request and Expectations ('Intake')

As we move to the second phase of the change management recipe (Analysis, scoping, prioritization, resource allocation, and project approval), we can see that suddenly the Chief Information Officer picks up (A)ccountability, while the Applied Clinical Informaticist has primary (R)esponsibility for the literature search, sponsor identification, workflow gap analysis, workflow development, scoping of deliverables, and identification of stakeholders. Together with a number of (C)onsultants including Clinical IT Analysts, Medical Librarians, Compliance, Regulatory, and Finance, they will also help review regulations and estimate a Total Cost of Ownership (TCO) and Return-on-Investment (ROI), providing much more helpful information for Senior Executives who will need to prioritize and approve this project before it can be assigned. (*Note : By serving this important workflow analysis role, the Applied Clinical Informaticist will also become a subject matter expert (SME) for other experts who will be (R)esponsible for later steps in the change recipe.)

Second phase of change : Analysis, scoping, prioritization, resource allocation, and project approval

Second phase of change : Analysis, scoping, prioritization, resource allocation, and project approval

When we arrive in the third (Project Planning) phase, now the Executive Sponsor has picked up (A)ccountability, while the Project Manager has primary (R)esponsibility for working with the Applied Clinical Informaticist, Clinical IT Analyst, and others to plan the necessary parts of the project, including Gantt charts, RACI Matrices, and/or other formal project plans :

Third phase of change : Project Planning and RACI Matrix / Gantt Chart Development

 

Third phase of change : Project Planning and RACI Matrix / Gantt Chart Development

Assuming all of the above phases have been completed, this now brings us to the fourth phase of change - The drafting of workflows, for which the Applied Clinical Informaticist has primary (R)esponsibility, typically in conjunction with the Clinical IT Analyst, Compliance, and the End-users. 

Fourth phase of change : Drafting of Workflows

Fourth phase of change : Drafting of Workflows

While some organizations may not yet have implemented blueprints in their development process, this step can be very helpful because :

• Blueprints help to create understanding, align clinical stakeholders, let you conduct tabletop workflow discussions and reviews, and obtain preliminary approvals before the Clinical IT Analysts begin their build (in the next step).
• Once approved, and with a few small changes, blueprints can also become your downtime forms, in case your electronic system is ever down for planned maintenance or other unplanned reasons.

This now brings us to the fifth and sixth phases of change, the building of deliverables and testing of workflows, where the Clinical IT Analyst now has primary (R)esponsibility to build and test the deliverables, typically in conjunction with the Applied Clinical Informaticist and the End User (for end-user acceptance testing).

Fifth and sixth phases of change : Building of deliverables and testing of workflows

 

Fifth and sixth phases of change : Building of deliverables and testing of workflows

For the seventh phase of change (Final workflow approval), the Applied Clinical Informaticist now assumes primary (R)esponsibility and works to secure the necessary final approvals in conjunction with Senior Leadership and a number of other stakeholders. (*Note that the Executive Sponsor still has (A)ccountability for this step.)

Seventh phase of change : Final Workflow Approvals

 

Seventh phase of change : Final Workflow Approvals

 

Finally, for the eighth phase (Communication and Education/Training), ninth phase (Implementation/Publication), and tenth phase (monitoring and support) of change, the Clinical IT trainers, Clinical Education / Training team, Communications Team, and End-Users now all share (R)esponsibility, and typically do their steps in conjunction with the Applied Clinical Informaticist and the Clinical IT Analysts.

Eighth, ninth, and tenth phases of change : Communication, Education, Implementation, Monitoring, and Support

 

Eighth, ninth, and tenth phases of change : Communication, Education, Implementation, Monitoring, and Support

IN CONCLUSION : 

What does this exercise (combining change management recipe with a RACI responsibility assignment matrix) teach us? Five helpful take-home points : 

1. Clinical change management is a team sport that requires the participation of a large number of stakeholders to work together in a clear, highly-detailed, highly-coordinated fashion, where different roles will be (A)ccountable for some steps, have primary (R)esponsibility in some steps, serve as a (C)onsultant in other steps, and need to be (I)nformed of other steps.
2. The roles of the Applied Clinical Informaticist and Clinical IT Analyst are separate and distinct roles that often work together, but serve in distinct and unique capacities, and thus should have separate and distinct job titles and descriptions.
3. Before projects are approved, the Applied Clinical Informaticist has primary (R)esponsibility for the analysis, scoping, prioritization, and resource allocation, typically in conjunction with (C)onsulting expertise from the Clinical IT Analyst, End-users, Compliance, Regulatory, Finance, Executive Sponsor(s), and Senior Leadership.
4. The Applied Clinical Informaticist also has primary (R)esponsibility for the drafting of workflows (blueprints of deliverables), typically in conjunction with (C)onsulting expertise from the Clinical IT Analysts, Compliance, and End-Users. These blueprints will help to create understanding and alignment, and later serve as downtime forms in the event of a planned or unplanned downtime. 
5. The Clinical IT Analyst often provides (C)onsulting expertise during earlier analysis and scoping phases of the change, but then assumes primary (R)esponsibility for the building and testing of electronic deliverables, before providing additional (C)onsulting expertise during the implementation phase of the change. 

I know there's a lot to unpack here, but I hope this review helps to demystify the process, and helps you look at your own change recipe and the roles that are (A)ccountable for,  (R)esponsible for, (C)onsulting on, and (I)nformed of each step. I also hope it helps to dispel the misunderstandings and confusion about the roles of the Applied Clinical Informaticist and the Clinical IT Analyst, two important roles that often work together but each of which require their own skill sets, job titles, job descriptions, and support.

Remember, the above is all a [ DRAFT ] and this blog is for educational and discussion purposes only - Your mileage may vary! Have any feedback or experiences you would like to share? Please feel free to leave comments in the comment section below!

Definitions, Templates, Documents, and Workflow Design - the Video!

Hi fellow CMIOs, CNIOs, and other Informatics friends,

I'm writing today to share a video adaptation of a lecture I did last year for a Physicians in AMIA meeting (thanks to Dr. Richard Schreiber!), where I shared a bunch of the lessons I've learned during my 16-year career as an Applied Clinical Informaticist and CMIO. 

If you're interested in Applied Clinical Informatics or workflow design, I think you'll like this video. My adapted version is about 26 minutes long, but it contains as much information and background as I could fit. And with a standard YouTube format, you can now pause and resume on any slide!

(Click above icon to open)

So if Applied Clinical Informatics, workflow design, or reducing clicks and burnout are your thing, I hope this video helps you. Please feel free to leave questions or feedback in the comments section below!

And for those of you who prefer printed slides, instead of video - I'm also working on a printed version of this presentation shortly!

Have any helpful experiences in developing clinical workflows? Or just want to share any lessons learned? Feel free to leave feedback in the comments section below!

Optimizing Lumbar Punctures, Part I

Hi fellow Clinical Informaticists, CMIOs, CNIOs, #workflow gurus, and other #HealthIT friends,

How do you say 'Lumbar Puncture' in CPOE? Today, I'm writing to share the translation of one of the oldest, most common medical procedures that's routinely done in modern healthcare : The lumbar puncture, sometimes referred to as an 'LP'.

Lumbar punctures (LPs) are routinely performed to help look for infections, look for malignancy, and look for antibodies and other markers of neurologic disease. While they are a common mainstay of modern healthcare, building them electronically can be quite a challenge. 

Want to reduce clicks when ordering your LPs? It helps to first have a solid understanding of the most common LP workflows in healthcare, so you can build your order sets with the most common studies, priorities, indications, and order statuses all properly built and correctly defaulted.

So in this post, I figured I'd share some secrets about the four most common lumbar puncture workflows, and how to build them into an EMR, in a really gourmet fashion - for the best diagnostic yield, fewest clicks, and maximal success. 

1. THE WORKFLOWS

Lumbar punctures are commonly done for diagnostic purposes, but can also sometimes be done for therapeutic purposes. But as it turns out, the LP is not just one workflow - It's actually four different workflows : 

In each of these scenarios, there are different clinical specialties using the LP, commonly for different purposes : 

In addition to these workflow descriptions, some helpful notes : 

• In workflows #2 and #3 above, there is a often a communication challenge between the ordering provider and the Interventional Radiologist, who has to collect, label, and transport the samples to the lab, and also report back some findings to the ordering provider (e.g. opening pressures, turbidity, etc.)
• In workflow #3 above, there is also sometimes a patient education challenge, whereby the patient needs to come before the scheduled IR LP to have 'pre-procedure' labs drawn (e.g. CBC, BMP, PT/INR) to help ensure that the LP can proceed without problems. 

2. THE STAKEHOLDERS

Given the above workflows, the physician specialties most commonly involved with lumbar punctures then include :

1. Emergency Medicine
2. Inpatient Physicians - Pulmonary/Critical Care (Intensivists)
3. Inpatient Physicians - General Inpatient Medicine (Hospitalists)
4. Interventional Radiologists (IR)
5. Ambulatory/Inpatient Specialists - Infectious Disease Physicians
6. Ambulatory/Inpatient Specialists - Neurologists - General
7. Ambulatory/Inpatient Specialists - Neurologists - Movement Disorders
8. Ambulatory/Inpatient Specialists - Neurologists - Multiple Sclerosis
9. Ambulatory/Inpatient Specialists - Neuro-ophthalmologists
10. Ambulatory/Inpatient Specialists - Hematology/Oncologists

If we include :

• the Registered Nurses (who have to help care for the patient before/after lumbar punctures), 
• the pharmacists (who help provide the medications the provider has ordered for sedation/anesthesia)
• the laboratory workers (who receive the fluid, provide the on-site analysis of certain labs, and send out other labs to external labs) 
• the IT/Informatics workers (who connect with stakeholders, map the current state, and work with the clinical stakeholders to design, build, and test the future state)

... then this gives us a fairly long list of stakeholders in the most common lumbar puncture workflow discussions : 

1. Emergency Medicine Providers
2. Inpatient Physicians - Pulmonary/Critical Care (Intensivists)
3. Inpatient Physicians - General Inpatient Medicine (Hospitalists)
4. Interventional Radiologists (IR)
5. Ambulatory/Inpatient Specialists - Infectious Disease Physicians
6. Ambulatory/Inpatient Specialists - Neurologists - General
7. Ambulatory/Inpatient Specialists - Neurologists - Movement Disorders
8. Ambulatory/Inpatient Specialists - Neurologists - Multiple Sclerosis
9. Ambulatory/Inpatient Specialists - Neuro-ophthalmologists
10. Ambulatory/Inpatient Specialists - Hematology/Oncologists
11. Nursing - Interventional Radiology
12. Nursing - Floor/Bedside
13. Nursing - Clinics
14. Laboratory
15. Pharmacy
16. Clinical IT/Informatics

... and you'll quickly see why you it's helpful to have a good clinical informatics and project management team available, to help coordinate all of the meetings, discussion, architecture, building, testing, and approvals before you can go-live. In short : Optimizing LP order sets is usually a significant project effort, requiring many meetings.

3. THE LABS

With regard to the actual laboratories, it's helpful to keep in mind that workflows #1 and #2 are general-purpose LPs, usually for the emergent ruling out of CNS infection. It typically doesn't get much more complicated than that. So for Inpatient/ED purposes, the most common studies include : 

• CSF Cell Count and Differential
• CSF Gram Stain and Culture
• CSF Protein
• CSF Glucose
• (Occasionally CSF HSV PCR, if clinically indicated)

But for workflows #3 and #4, they are more specialty-oriented, so their labs may include the general labs above, but also include a number of complex, high-cost specialty panels, antibodies, proteins, and pathology / flow cytometry. 

Commonly, the occasional ordering of these specialty studies (commonly from workflows #3 and #4 above) in the Inpatient/ED settings (commonly workflows #1 and #2 above) can generate a lot of discussion. For reimbursement reasons, it's helpful to stratify these workflows, but keep in mind - In complex cases, there may still be reasons to order the more complex outpatient labs on an inpatient, but generally they should only happen with specialist review and approval.

4. THE ORDER SETS

So now you're faced with the question - One order set, or four order sets?

If you do one order set, you'll probably end up needing to stratify them (with radio buttons!) into the four different workflows, e.g. : 

Or, more likely for operational, culture, and other EMR configuration reasons, you may end up with four different order sets - In which case you will want to choose your naming convention very carefully, e.g. : 

1. LUMBAR PUNCTURE (LP) - INPATIENT/ED - AT BEDSIDE
2. LUMBAR PUNCTURE (LP) - INPATIENT/ED - IN IR
3. LUMBAR PUNCTURE (LP) - AMBULATORY/OUTPATIENT - IN IR
4. LUMBAR PUNCTURE (LP) - AMBULATORY/OUTPATIENT - IN CLINIC

Even though #1 and #2 above are typically used by generalists, and #3 and #4 above are typically used by specialists - You'll still want to have specialty input into #1 and #2, to help make sure that the common specialty scenarios can still be addressed (when they arise) in the inpatient settings. (E.g. Having Infectious Disease provide input into #1 and #2 can help make sure your ED providers/Hospitalists/Intensivists are ordering the right ID labs for the right scenarios.)

In my next post, we will look at these four LP workflows in more detail, and discuss some of the common educational, operational, and ordering challenges that organizations may come across when building out and optimizing these order sets. 

Have any thoughts, comments, feedback, or stories to share about building highly-optimized (gourmet!) lumbar puncture workflows? Feel free to leave in the comments section below!

Remember, this blog is for educational / discussion purposes only, and does not constitute medical advice - Your mileage may vary. Always consult your clinical leadership, your clinical informatics team, and your medical specialists before building out any order sets in your own organization.

Top 15 Signs You May Work in Clinical Informatics

Hi fellow CMIOs, CNIOs, Clinical Informaticists, Clinical Informaticians, and other #workflow and #HealthIT friends,

Over the last 10 years, I've blogged a lot about different topics in applied Clinical Informatics, from change management to glossary development and workflow terminology management, to order set development. And yet, across the industry, it can sometimes be a challenge to find the other people who do this type of work, partly because: 

• There are some people who 'do Clinical Informatics work', but are not labeled Clinical Informaticists / Clinical Informaticians in their job title. (Some are labeled CMIOs, CNIOs, Directors of Clinical Informatics, Clinical IT Analysts, Business Analysts, etc.)
• There are some people who do have a job title like 'Clinical Informaticist/Clinical Informatician', but focus their efforts mostly on a particular branch of Informatics, without clear support for the other branches (often due to resource limitations).
• Some 'Clinical Informatics' people focus their work for only their clinical specialty (e.g. 'Physician Informaticist', 'Nurse Informaticist', etc.)

So since in some regions, applied Clinical Informatics in 2020 still seems to be an emerging field, one that is fortunately becoming more formal and structured with the advance of more formal training and certification programs - I decided to spontaneously write a humorous piece on Twitter that could appeal to the 'Clinical Informaticist' (or 'Clinical Informatician') in all of us : 

Feel free to share with any Clinical Informaticists (or Clinical Informaticians) you know with a sense of humor! :)

Remember, this blog is for education and discussion purposes only - Your mileage may vary. Have any helpful humor or insights about Clinical Informatics, job titles, and professional development? Feel free to leave them in the comments box below!

Teaching Example : The Ice Cream Order Set

Hi fellow #ClinicalInformatics, #Informatics, #HealthIT, #CMIO, #CNIO, #CPOE, #workflow, and other #design thinking friends, 

Order sets - If you work in Clinical Informatics, you probably have a lot of experience with them. 

Order sets offer great opportunity, and can really help streamline clinical processes and create predictable outcomes. Since they are a part of the medical record that every doctor uses (like Larry Weed, MD once said), they can help guide and teach. In my 13 years of designing them, I've seen remarkable standardization in processes, reduction in variation, and improved outcomes when they are designed well. 

For those who design and build them, however, here are the five most common challenges : 

1. People without solid order set experience often don't budget properly from them, from a time or resources perspective. (They often take more work than most people would initially imagine.)
2. Doing them well often requires a great deal of effort and coordination between multiple clinical stakeholders (Physicians, Nurses, Pharmacists, and often other ancillary services, operational leaders, finance, legal/compliance, etc.)
3. It's not just the effort to create them - It's also the effort to maintain them.
4. People often disagree about the best way to create, review, test, approve, and publish them. 
5. Managing expectations can take time, especially when people try to use them to solve complex training/education or utilization problems. 

There are actually best-practices for developing them, but they're often not well-understood. It often takes time to build them in a collaborative manner, to help ensure the best outcomes: Order sets that physicians will actually *use*, predictably, to achieve predictable outcomes. 

So recently on Twitter, my CMIO colleague Paul Fu, MD from UCLA shared a tweet about an EMR order for 'birthday cake', presumably from a pediatric hospital that had actually had built an order for pediatric patients who could tolerate a piece of birthday cake on their birthday.

While several Clinical Informatics friends chimed in to comment, I took the opportunity to create a tongue-in-cheek, general-purpose Ice Cream Order Set that could actually be used for teaching and discussion purposes : 

This [DRAFT] order set example above basically lets you prepare ice cream for your TV binge-watching purposes. Remember, It's not a real order set, but it's a decent teaching example to show just how complicated and workflow-dependent order set design can be. 

You'll notice that it's a general-purpose ice-cream order set, addressing some common scenarios : 

• It's fairly flexible, allowing you to eat as little as a single scoop in a bowl or cup, or as much as multiple pints.
• It does a decent job addressing common allergies (lactose, peanut, dairy, etc.)
• It uses fairly standardized units of measurement, which are reasonable for most ice-cream consumption purposes. 
• It lets you select a number of toppings - and even finishes with a cherry on top. 

You'll also notice that it has some limitations : 

• It only offers three flavors - Chocolate, strawberry, and vanilla. (Imagine trying to index an order set to offer more complex flavor combinations?)
• While it has decision-support built in to help guide an ordering provider to the right choices, it does require a doctor to order the ice cream differently, depending on the utensils and container (cup/bowl versus the ice-cream container)
• Some Clinical Informatics friends have suggested it should have some alerts and hard-stops for people with certain food allergies (e.g. should you be able to order peanuts if you have a peanut allergy?)

Of course, it's just ice-cream, but the order set is still fairly complex, and required the development of a new term ('unique container') to address the ordering workflow related to eating from bowls/cups versus the ice-cream container - Imagine creating order sets for complex or high-risk clinical workflows.

Feel free to share this teaching example for your own discussion or education purposes - If you don't use an EMR or don't use order sets, it's a friendly way of showing people the promise and complexity that order sets can present, both in development and use.

Remember this blog is for discussion and education purposes only - Your mileage may vary. What would you do to make this order set easier or offer more flavors? Do you have any tips or feedback about order set development or maintenance? Feel free to leave them in the comments section below!

How to Untangle a Complex Clinical Workflow

Hi to my fellow #CMIO, #CNIO, #ClinicalInformatics, #Design, #Designthinking, #workflow, and #HealthIT friends,

For today, I thought I'd share an easy trick for untangling even the most complicated clinical workflows. 

Let's say you're asked to help troubleshoot a particularly complicated workflow, where the end-users tell you things like 'It's so complicated, I can't even describe it!', or 'It's very non-linear'. You want to help, but aren't sure where to start. 

Here's my tip : Start by just writing procedures. 

While many people in the industry commonly write their workflows as 'swimlane' workflow diagrams, I find that these can sometimes quietly have room for error. In the wrong hands, with an untrained eye, it's possible to draw up a swimlane diagram with 'hidden gaps' that are hard-to-spot until you talk through each step in the process, usually with a group of end-users.

Indeed, swimlanes are the usual industry standard for planning or troubleshooting complex workflows, but writing good procedures can be equally as effective, with some added benefits : 

• Procedures can usually be edited dynamically, on-the-fly, with a group of people (e.g. in a video conference), as an easy way of quickly collecting their understanding of their workflow/process. 
• Procedures also make it easier to spot missing pieces - If you use my format above, you'll always know when the WHO (stakeholder) is missing, when it's not clear what's a REQUIRED (will) task or an OPTIONAL (may) task, or what exactly the task is. 
• Procedures can also usually be easily converted into policies or education, for those times when you want a policy to help back up and reinforce your important procedure, or educate it out to the people who need to follow your new workflow/procedure.
• Procedures are also generally 'naturally lean'. Missing pieces, redundancies, or design problems usually become obvious as you write out the procedure, allowing you to address those questions before you build your new process. 

If you use the procedure outline above, with the optional modifiers - you can even estimate the time it takes to do each task, allowing you to estimate the total time, people, and resources you will need to achieve your desired outcome. This can even be helpful in developing a Total Cost of Ownership (TCO) and Return-on-Investment (ROI) for your workflow.

And it's generally easier to stitch procedures together than it is to try to stitch swimlane workflows, which can take some time to move objects around, edit text, and reformat the diagram. 

Finally - For extra clarity, you can even name your procedures exactly what they are, e.g. : 

• DRAFT - CURRENT STATE - How to cook good food
• FINAL - CURRENT STATE - How to cook good food
• DRAFT - FUTURE STATE - How to cook even better food
• FINAL - FUTURE STATE - How to cook even better food

If you have any tips you'd like to share for documenting or troubleshooting workflows, feel free to leave them in the comments section below!

Remember, this blog is for educational and discussion purposes only - Your mileage may vary! Please check with your Clinical Informatics, Legal/Compliance, or Clinical Operational leadership before documenting any of your own workflows. If you have any feedback, tips, or tricks you'd like to share - Feel free to leave them in the comments section below!

Developing Communication and Education Strategy for Providers

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

A short blog post this month. 

Provider burnout (including physicians, nurses, residents/housestaff, and APPs) is a real issue, and having both good communication and training strategies can be a real help in making things easier for everyone - both sender and recipient of your many important messages.

So to help reinforce my message about the importance of good workflow design, I took the liberty of adapting my recent post on Signal-to-Noise, Provider Communication, and Provider Education, into this 11-minute video below : 

From https://youtu.be/uayY1JCfREk 

The animated discussion about signal-to-video is intended only to stimulate discussion about the importance of managing both signal and noise across your clinical spectrum, for front-line providers and other clinical staff who are both on-and-off duty. 

I hope this helps stimulate strategic discussions in your own settings! If you have any helpful communications or education tips, feel free to leave them in the comments section below. 

Remember, the above is for educational discussion only - Your mileage may vary. Always check with your Senior Leadership, Clinical Leadership, Legal/Compliance, and Clinical Informatics teams before considering any kind of strategic changes in your own organization.

Have any helpful tips, suggestions, or feedback? Feel free to leave in the comments section below! 

Intro to CPOE and Order Sets

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

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

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

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

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

Remember, this blog is for educational purposes only - Your mileage may vary. Have any other comments or feedback? Please leave them in the comments section below!

Improving EMR Satisfaction by Better Anticipating Clinical Needs

Hi fellow CMIOs, CNIOs, Clinical #Informatics professionals, and other #Healthcare leaders,

I'm writing today to share my thoughts about how to improve EMR user satisfaction through a better understanding of the user's clinical roles and responsibilities, and how they impact EMR configuration and training. 

Allow me to explain. Imagine you see a group of people with white coats and stethoscopes, eating lunch together. What are their needs? Are they all one kind of provider, or different providers? How could you tell them apart? And even if you could somehow tell them apart, how would you know exactly what their EMR configuration and training needs are?

Most clinical people think of these as small details. To them, clinical roles seem fairly intuitive, and credentialing seems like little more than a time-intensive requirement to 'do paperwork' before you can begin working clinically. Both of these are common misunderstandings. 

The truth is that clinical roles in modern healthcare are very nuanced, each with their own clinical functions and supervisions needs, and so your exact clinical role and responsibilities have an enormous impact on your EMR configuration and training needs. Without a clear understanding of your clinical role and responsibilities, it's very  challenging to provide the right EMR configuration and training, which can lead to frustrated end users.

So to help improve EMR configuration, training, and user satisfaction - I thought I'd offer this little blog post to help you understand how clinical role terminology, supervision requirements, and onboarding/credentialing questions can help improve EMR configuration and training, as well as end-user satisfaction. 

So in short, we'll discuss some basics about four topics : 

• A - What is a Doctor (Physician)? What are the different types of Doctors (Physicians), and when/how are they supervised?
• B - What is an Advanced Practice Provider (APP)? What are the different types, and when/how are they supervised?
• C - What is a Provider (Prescriber)?
• D - What kind of questions can you ask during on-boarding/credentialing to help make sure you fully understand the provider's role and responsibilities, so you can better anticipate their needs and provide great configuration and EMR training?

Let's get started!

A. WHAT IS A DOCTOR (PHYSICIAN)?          
For those of us who have been through medical training, this all seems fairly intuitive. You finish medical school, get through internship, complete your residency, and many docs continue through a fellowship (subspecialty) training, before becoming an Attending Physician. And along the way, you will work with lots of great Advanced Practice Providers (APPs) including Advanced Practice Registered Nurses (APRNs), Physician Assistants (PAs), and others. 

But imagine if you weren't clinical. Looking at a group of people with white coats and stethoscopes, how could an administrative or IT person tell them apart? It helps to have some good definitions to work with!

Let's start by looking at what exactly is a "Doctor" (Physician).

Note that the supervision model above requires a number of workflow configurations in an EMR - Most commonly, with orders and clinical documentation (notes) - 

• Which order(s) WILL require an attending countersignature?
• Which order(s) will NOT require an attending countersignature?
• Which note(s) WILL require an attending countersignature?
• Which note(s) will NOT require an attending countersignature?
• Knowing the EMR will function differently for Residents, Fellows, and Attendings - How will the EMR be configured for Fellows who sometimes moonlight as Attending providers?

In addition to a clear understanding of these roles, responsibilities, and configuration differences - It's also important that an organization have an easy way of knowing when doctors change their roles. (July 1st is not a guarantee that a doctor's clinical role will change!)

B. WHAT IS AN ADVANCED PRACTICE PROVIDER (APP)?       
With the expansion of medical technology and clinical specialties in the 1970s and 1980s, came a new set of providers who could help 'extend' the reach of the attending physician, including Advanced Practice Providers (APPs) such as : 

These roles also have unique EMR configuration and training needs, which are highly dependent on the supervision needs, which often depend on state regulations. Like Doctors/Physicians, having a clear understanding of these clinical roles and their supervision needs is key in providing the proper configuration, security, and training. 

C. SO WHAT EXACTLY IS A "PROVIDER" (PRESCRIBER)?      
So to put this all together, we can now represent the Doctors (Resident, Fellow, and Attending Physicians) and Advanced Practice Providers (APPs) as a common set of Providers (Prescribers), each with a DEA number and prescriptive authority, but with different supervision needs and expectations : 

Again, this catch-all term can be helpful, especially for pharmacies that want to provide services to all of these roles. It's not as helpful in legal/billing scenarios, where usually the Supervising Attending Provider (1c) (and sometimes the independent APRN!) are more commonly the focus of discussion.

D. CREDENTIALING AND EMR CONFIGURATION AND SUPPORT
So we've discussed how these clinical roles impact EMR security, configuration, and training. What other questions can you ask, to better anticipate a user's clinical needs, configuration needs, and training needs? While it may not be comprehensive, I recently drafted this list of questions you might ask a provider during on-boarding and credentialing, to better understand and anticipate their clinical, academic, research, and administrative needs:  

Again, this list of questions may not be comprehensive, but it helps show how good credentialing and provider on-boarding can help HealthIT people to better understand a user's clinical, administrative, research, and academic roles, and anticipate the specific needs for each role. 

I hope this was helpful in shedding some light on these important topics! Remember : It's the little details that matter. If you have any feedback or comments, please leave them in the comments section below.

Remember this blog post is for academic and educational discussion only - Your mileage may vary, and always check with your local Legal, Compliance, and Clinical Informatics experts for guidance in your own organization. Have any feedback or thoughts? Feel free to share below!