Tips and Tricks for Clinical Workflow Redesign

 Hi fellow CMIOs, CNIOs, and other Informatics friends,

Today I thought I'd share some materials I delivered in a talk back in 2023 for Dr. Judi Binderman, a really seasoned Clinical Informaticist and good friend of mine. I recently discovered these when going through some old slides. At the time, Dr. Binderman had asked me to speak briefly to her team at Community Medical Centers in Fresno, CA about some helpful tips and tricks of clinical workflow redesign : 

My talk was mostly related to workflow analysis, change management, documenting workflows, and workflow design. So I opened up first with a brief discussion about workflow analysis and change management : 

The first point that I usually emphasize for any new Clinical Informatics leaders is that work can be measured and estimated through a workflow gap analysis. The distance from the current state to the future state gives you a good estimate of the stakeholder(s) you will need to involve in a project, what they will need to learn and do (to achieve your future state), and so this gives you a good estimate of your project deliverables and project scope (for planning purposes) :

Once you have completed your gap analysis to get a sense of the current-state and future-state workflows, you can then review a list of common deliverables, to select what you will need to get your users from current to future state : 

Note that some of these deliverables (above) are inside of the Electronic Health Record (EHR), and other deliverables are outside of the EHR. You will want to identify all of the deliverables you anticipate needing/using, and then identify who you will need on your project team to help develop each deliverable.

Remember that workflow change management is a team sport - A common mistake is to think that you can make a change with 'only Doctors' or 'only Nurses'. Almost all clinical workflows depend on many stakeholders, from different enterprises, with a number of different roles. Understanding the different enterprises of your organization, and the different roles you may engage with, is helpful to make sure you've thought through all of the stakeholders you will need to make your project successful : 

Once you have a sense of the estimated stakeholders and deliverables, it's helpful to think through the steps you will need to develop your workflow. For teaching purposes, I usually shrink this down into ten (10) easy steps, that you can talk through with your development team : 

This discussion almost always brings up the debate (question?) about change / project management methodologies. Two common methodologies include : 

• Waterfall Methodology - Linear, step-by-step, good for plan-first approach, takes longer but especially well-suited for Healthcare or new high-risk scenarios where one build is all you can plan for.
• Agile (Software Development) Methodology - Iterative, emphasizes rapid feedback and adaptation, sometimes useful when clinical workflows are evolving or need user-centered design - but not ideal for Healthcare scenarios. Better built for speed and iterations.

Some people will argue that Waterfall can take too long, and they prefer the speed and flexibility of Agile. Personally, I'm not sure how well Agile fits into the many high-risk clinical workflows of Healthcare (since there is usually little room for error), and so I've condensed those ten (10) helpful steps in the slide above into this 'general-purpose change recipe' below :

Once you've gone through the exercise of writing out those ten steps, and developing your own change recipe - You can then import it into a spreadsheet, and add your common roles across the top to build out your own Responsibility Assignment (RACI) Matrix : 

This Responsibilty Assigment (RACI) Matrix can then walk you through the first step of your change management - Documentation of Request and Expectations ('Intake') - And help you to develop key questions that your requestor and their supervisor (e.g. Chief, Chair, or Director) can answer before you do further analysis.

Once you have their preliminary input and feedback, you (Clinical Informaticist) can then pursue the next steps of your journey - Analysis, scoping, prioritization, resource allocation, and project approvals - To help evaluate and develop the request, and make sure your Clinical and Administrative Leadership have the information they need to prioritize and approve the project : 

After your Administrative and Clinical Leadership understands :

• the project priority, estimated scope, estimated stakeholders, estimated deliverables, and necessary resources, 
• the estimated Total Cost of Ownership (TCO) and Return on Investment (ROI)

... they can effectively prioritize and approve the project, leading you to formal project initiation, project development, and the drafting, building, testing, approval, education, implementation, and support of your future-state workflows : 

So - What tips can I offer a new Clinical Informaticist for documenting workflows and workflow design?

My first tip is to closely examine the similarities between a 'Swimlane diagram' (Visio) and a Procedure : 

If we break down a a 'Swimlane diagram' (Visio), it basically answers the questions : 

Q : Who is doing what, and in what sequence (order)?

So with a small adaptation, we can revisit the traditional swimlane diagram as :

... which leads me to share a helpful discussion of what exactly a procedure is (adapted from Charles Webster, MD aka @wareflo, another brilliant Clinical Informatics mind I have had the fortune of learning from)

Procedure (n.) (synonym : workflow, recipe, process, algorithm) - An ordered series of tasks that uses people, time, and resources to achieve a desired goal or outcome.

Now, if you accept the definition above as true, then you can create a simple template for writing a task, the most basic building block of a procedure (synonym : workflow, recipe, process, algorithm) : 

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

where : 

• [ WHO ] = Role of the person that will perform the task
• will/may = Use "WILL" for required tasks, "MAY" for optional tasks
• [ WHAT ] = Brief description of the task
• { how } = Optional modifier, use only when needed to clarify how the task is performed
• { when } = Optional modifier, use only when needed to clarify when the task is performed (for timing/duration)
• { where } = Optional modifier, use only when needed to clarify where the task is performed
• { why } = Optional modifier, use only when needed to clarify why the task is formed

You can then include this in your own 'workflow glossary', where you define and organize your favorite high-grade (policy-grade) terminology related to workflow design : 

... but you can also use it to start writing out procedures for all sorts of things. My favorite teaching example is to take a poorly-written process (in this case, a poorly-developed process for baking and delivering cupcakes) :  

... and turn this into a well-developed process that identifies not only the necessary steps and deliverables of the workflow, but also the necessary stakeholders and their Directors/Chiefs : 

So that's a very helpful skill for the new Clinical Informaticist - Learning how to write an effective procedure. Procedures create clarity and helps you develop solutions. And this also means that your policy manual will be an excellent source of common clinical workflows, their stakeholders, and their deliverables : 

Plus, once you understand how to write a task and a procedure, you can then easily estimate the cost of the procedure by assigning either : 

• Cost = Labor + Materials
• Cost = (Salary * Time) + Materials

... to each step : 

Just for fun, you can use this trick to estimate the cost of a box of macaroni and cheese, if different clinical roles made it : 

... and so, by writing out a procedure and assigning an estimated cost to each step -  you can see the different estimated costs for an MD, an RN, a LPN, and a MA making mac and cheese :

Understanding this (and the regulatory scope-of-practice questions that naturally arise from this level of analysis) can not only help you estimate costs, but also save money, and help your clinicians to work at the top of their license - See the estimated cost of this workflow below, with an RN giving a cupcake to the patient : 

... versus the estimated cost of the workflow if an LPN gives the cupcake to the patient : 

And so, to summarize : 

And some helpful final thoughts : 

And one more final thought (wisdom once passed to me by another experienced Clinical Informaticist, early in my career) : If you're ever lost, start to untangle your workflows by writing a good procedure. 

I hope this has been a helpful journey into how to document, analyze, and develop your own clinical workflows. If you have any questions, please feel free to leave them in the feedback/comment section below! (And special thank you to both Dr. Judi Binderman and Dr. Charles Webster for their contributions to this post!)

REMEMBER : This blog is for education and discussion purposes only - Your mileage may vary. Have any other helpful tricks for quickly untangling or developing clinical workflows? Feel free to leave them in the comments section below! 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What can Cardiac Myocytes teach us about Teamwork and Workflow?

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

Today's post is short, but one that I think most clinical friends will understand and appreciate. For conceptual teaching purposes only, I'm going to ask the question : 

"Q : What can Cardiac Myocytes teach us 

about Teamwork and Workflow Design?"

Here's my theory : Clinicians may actually have an advantage here. If you've ever studied the human heart - it's anatomy, it's functions, its biology, and its electrophysiology - You already know a lot about teamwork, workflow design, clinical operations, and essentially how to get things done. 

After all, cardiac myocytes and humans (clinical leaders and team members) both work towards a common goal. We both can function as individual units, but we function even better together as a well-organized, well-synchronized team : 

[ DRAFT ] TABLE - A tongue-in-cheek but honest comparison of Myocytes with Humans (Clinicians)

Let's face it, healthcare is a team sport. So when I'm working with other clinical leaders, especially new ones - For support, I often remind them of the importance of the infrastructure and tools that, especially as clinicians, we sometimes take for granted - Good : 

• Regulations (both Federal and State)
• Governance (e.g. Committee structures)
• Leadership
• Direction
• Management
• Communication
• Bylaws
• Policies/Procedures
• Training / Onboarding
• Continuing Education
• Offboarding
• Teamwork

After all, when growing a plant - it's not just the seeds you need to worry about, it's also the soil. So without enough of this 'supporting soil' (the tools above) in place, it becomes very easy to run into problems growing the seeds - And so for end-users, managers, directors, leaders, and executives alike, this can sometimes result in loss of efficiency, frustration, disorganized workflows, problems not getting solved in a timely basis, etc.

Typically, these tools don't get enough attention from new clinical leaders, because until they are in a leadership position - their focus has largely been on 'clinical things' like working with patients, diagnosing and treating diseases, performing operations and procedures, etc. While those are all the reasons we are in healthcare, it's still important to understand the many 'non-clinical' tools that make those things happen. (In truth, those tools are just as clinical as penicillin - But due to time constraints, they usually don't teach much about them in medical schools.)

What I find especially interesting is that, as a physician who during my career has treated cardiac tachyarrhythmias at the bedside (using beta-blockers, calcium-channel blockers, adenosine, cardioversion, etc.) - There are often similar analogous ways to treat these same 'human tachyarrhythmia' problems on project teams : 

So when I have the opportunity to teach a new clinical leader about how to solve problems and function in teams, I simply remind them that modern human biology has evolved over thousands of years to solve these same sorts of problems that we experience in healthcare today - And so sometimes, looking inward with a microscope is just as helpful as looking outward with a telescope. 

Finally, one of my clinical informatics colleagues and good friend Stefanie Shimko-Lin, BSN RN CD-L CD-PIC FHIMSS once shared this cardiac analogy with me : "Collateral circulation is a workaround, that happens when the desired workflow doesn't work. If you make it easy to do the right thing, people will do it."

These analogies may all seem a bit peculiar and tongue-and-cheek, but if you're a clinical leader - I hope this blog post helps to spark helpful discussion and learning with your own clinical leadership and project teams, so that you can better solve the workflow and operational issues you might encounter in your daily clinical routines.

Remember, this blog is for educational and discussion purposes only - Your mileage may vary! Have any other helpful analogies or advice for new clinical leaders? Feel free to share them in the comments section below!

A Tale of Applied Clinical #Informatics, in Four Parts

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

Today I'm writing today to share a tale of Applied Clinical #Informatics, in four parts. (Or, "Why workflow analysis, naming conventions, indexing, and usability all really do matter.")

Feel free to leave comments at the end - Hope you enjoy it!

1. PART ONE - 

"I'm sorry, I don't have time to talk about workflow analysis, naming conventions, indexing, or usability - just give me everything I need in one place, and quick!!"

2. PART TWO - 

"Wait, that's not right, I can't use that. I still don't have time to talk about any of that workflow or usability stuff, but can you just put everything I need in one place so I can see it all and easily access everything I need with just one click?"

3. PART THREE - 

"Wait, that still doesn't look right, and I'm afraid I'm going to be scrolling forever. I still don't have the time to meet, but I heard there's some tool they use at another organization - Can you just find out what tool they use to do this, and then just put my stuff into whatever tool they use?"

4. PART FOUR - 

"OK, wait... I think I see the problem. Let's make some time to talk about workflow, including exactly what these tools do - Both what I use them for, and when I use them. Then let's talk about the naming conventions and indexing for each tool, so they all have a standard look and feel. Then let's talk about usability, so that I keep the most commonly-needed tools in one place, and the less common tools in a separate but nearby place. And then finally after you build it - I'll help test it to make sure it's both functional (what-we-need) and also easy-to-use."

"Eureka - That's it!" 

[ THE END ] 

Remember, this blog is for educational/discussion purposes only - Your mileage may vary. Have a good teaching example you'd like to share? Feel free to leave in the comments section below!

A Student's Take on A.I. in Healthcare

Hi fellow Clinical Informaticists, workflow designers, and other clinical architects,

Today's blog post is a slight deviation from my usual posts - It's actually a guest post, from a smart young college student, Paul Lestz, who I recently had the good fortune of working with on an educational internship.

Paul's particular interest is related to the use of Artificial Intelligence (A.I.), so we discussed the current state of A.I. in healthcare, and ways to implement this technology to a broader audience. 

So I'm very happy to report that, after reading Paul's blog post below, that 'The Kids Are Alright' - If this is what our future leadership looks like, then I have great confidence in our future. 

Please enjoy Paul's post below : 

______________________________

If after an exhaustive examination of data, an artificial intelligence (A.I.) algorithm were to recommend termination of care for a relative - how would you react? How would you feel if this type of recommendation or decision was made solely by an A.I. algorithm, with no clear human oversight? Does it help to differentiate a recommendation from a decision?

Currently, there are few industry-wide reasons to be concerned - at least so far. While some healthcare institutions have begun the deployment of A.I. systems, we are not yet dependent on them for these types of high-risk decisions. Human doctors still have responsibility and remain in control - which means now is a good time to educate ourselves on A.I., including its many compelling benefits, potential risks, and ways to mitigate those risks.
 
While reading, please remember - A.I. is a complicated topic, that warrants our attention. Turning a 'blind eye' to A.I. does not mean that the field will not continue to expand into every industry, including healthcare. I hope this post provides some helpful education - as a starting point for future discussions - and helps to reduce the initial intimidation that A.I. discussions often induce.

 

Why do I believe that A.I. will continue to expand into the healthcare industry? It's because of the many potential benefits of using A.I. to manage the high-risk scenarios that healthcare workers commonly encounter. Among others, here are some major benefits offered by A.I.:

 

Adapted from: Artificial Intelligence in Medicine | Machine Learning | IBM

• Cutting through the noise - A.I. can help make sense of the overwhelming amount of clinical data, medical literature, and population and utilization data to inform decisions.

• Providing contextual relevance - A.I. can help empower healthcare providers to see expansively by quickly interpreting billions of data points - both text and image data - to identify contextually relevant information for individual patients.

• Reducing errors related to human fatigue - Human error is costly and human fatigue can cause errors. A.I. algorithms don’t suffer from fatigue, distractions, or moods. They can process vast amounts of data with incredible speed and accuracy, all of the time.

• Identifying diseases more readily - A.I. systems can be used to quickly spot anomalies in medical images (e.g. CT scans and MRIs).

From my perspective as a student, these are all compelling examples of how A.I. could help develop healthcare into a more modern, efficient, and reliably data-driven patient-care system.

 

To do this, however, also requires an examination of the challenges that A.I. can bring with it - unsurprisingly, extremely new technology sometimes brings unexpected issues. Some of the known challenges of A.I. implementation include: 

 

Adapted from: The Dangers of A.I. in the Healthcare Industry [Report] (thomasnet.com)

• Distributional shift - A mismatch in data due to a change of environment or circumstance can result in erroneous predictions. For example, over time, disease patterns can change, leading to a disparity between training and operational data.

• Insensitivity to impact - A.I. doesn’t yet have the ability to take into account false negatives or false positives.

• Black box decision-making - With A.I., predictions are not open to inspection or interpretation. For example, a problem with training data could produce an inaccurate X-ray analysis that the A.I. system cannot factor in, and that clinicians cannot analyze.

• Unsafe failure mode - Unlike a human doctor, an A.I. system can diagnose patients without having confidence in its prediction, especially when working with insufficient information.

• Automation complacency - Clinicians may start to trust A.I. tools implicitly, assuming all predictions are correct and failing to cross-check or consider alternatives.

• Reinforcement of outmoded practice - A.I. can’t adapt when developments or changes in medical policy are implemented, as these systems are trained using historical data.

• Self-fulfilling prediction - An A.I. machine trained to detect a certain illness may lean toward the outcome it is designed to detect.

• Negative side effects - A.I. systems may suggest a treatment but fail to consider any potential unintended consequences.

• Reward hacking - Proxies for intended goals sometimes serve as 'rewards' for A.I., and these clever machines are able to find hacks or loopholes in order to receive unearned rewards, without actually fulfilling the intended goal.

• Unsafe exploration - In order to learn new strategies or get the outcome it is searching for, an A.I. system may start to test boundaries in an unsafe way.

• Unscalable oversight - Because A.I. systems are capable of carrying out countless jobs and activities, including multitasking, monitoring such a machine can be extremely challenging.

• Unrepresentative training data - A dataset lacking in sufficient demographic diversity may lead to unexpected, incorrect diagnoses from an A.I. system.

• Lack of understanding of human values and emotions - A.I. systems lack the complexity to both feel emotions (e.g. empathy) and understand intangible virtues (e.g. honor), which could lead to decisions that humans would consider immoral or inhumane.

• Lack of accountability for mistakes - Because A.I. systems cannot feel pain and have no ability to compensate monetarily or emotionally for their decisions, there is no way to hold them accountable for errors. Blame is therefore redirected onto the many people related to the incident, with no one person ever truly held liable. 

Rather than feel discouraged when comparing the benefits of A.I. versus these risks above, I'd like to share that there are solutions to many, if not all, of these known risks above - through commitment and detailed policy work.

 

For instance, let’s take a look at the challenge underlined above: automation complacency. At first glance, one might think it would be too difficult to resolve this extremely conceptual issue, intrinsic to the mind of the clinician. However, automation complacency serves little to no problem if the following workflow is implemented: 

 

(Sample policy/workflow for managing automation complacency - Click to enlarge)

 

I designed this visual to help simplify the complex process of reducing automation complacency to a few, easy-to-follow steps.

 

Resolving the issues related to A.I. does not mean instantly coming up with a single, lengthy procedure in the hopes that it will work. Instead, resolving challenges means breaking the problem down into pieces and isolating different steps in order to achieve the desired result.

 

When developing the flow chart above, I had to determine what exactly was the root of the unwanted issue: 

 

Q: How could a clinician be biased towards picking the A.I. algorithm’s result without considering alternatives? 

A: It would most likely be because they knew the A.I.’s prediction before/at the time they made their initial diagnosis. 

 

While we, as humans, might think that we are not biased by certain information, this assumption is often an illusion. Subconscious biases tend to be the most powerful because we do not realize how much they affect us.

 

In order to solve this problem, my workflow above mandates that the clinician provide and lock in their initial opinion before being provided the A.I. algorithm’s prediction. By doing so, we resolve our first issue of initial, subconscious biases.

______________________________

 

As I have just demonstrated, solving A.I.-related issues is often a matter of breaking down problems and coming up with small solutions that together, sum up to a working whole.

 

So, if there are often ways to mitigate the risks of these A.I.-related issues - are we good to go? The answer: it’s complicated.

 

Often, users (e.g. healthcare institutions) are not actually making their own algorithms. Instead, they purchase them. Therefore, one must consider various factors in deciding which A.I. algorithms to purchase. Unfortunately, after an extensive literature search, it doesn't appear that there has been a helpful, cohesive guide as to what factors to consider when purchasing A.I. solutions, so I would like to propose the following guidelines:

 

 

(Sample questions to consider in A.I. purchasing - Click to enlarge)

I created the infographic above to help frame some helpful questions to ask a vendor when considering the purchase of an A.I. solution.

______________________________

 

Generally, I hope that this piece helps to serve two primary purposes: 

1. The first is to convince you that, with good understanding and planning - A.I. typically brings about more good than harm in the world. 

2. (This second purpose assumes that you have already embraced the first) - The second purpose is to convince you not to take A.I. for granted, but to be thoughtful in the approach so that institutions (and the people who work at them) solve problems, purchase algorithms, and engage with the world of A.I. responsibly.

It's generally important to prepare and 'do your homework' before engaging in A.I. discussions. This preparation is especially important if we want to maximize the benefits of A.I. and minimize the risks. This post’s goal, therefore, is to bring the focal point of A.I. not to its use, but to its purchase. After all, a well-considered purchase combined with a thoughtful implementation often leads to more responsible ownership and successful outcomes. Alternatively, inadequate preparation can lead to unexpected outcomes. 

______________________________

 

As a student, and without a deeper knowledge of the exact workflow expectations for a particular circumstance, I am unfortunately unable to offer any more-detailed perspectives. However, I hope this initial post helps to 'get the ball rolling' on some important discussions related to proper A.I. planning, purchasing, and use. The right answers will still need to be evaluated and defined by planners, users, regulatory agencies, and society.

______________________________

Remember this blog is for educational and discussion purposes only - Your mileage may vary. Have any thoughts or feedback to share about A.I. in Healthcare? Feel free to leave in the comments section below!