Friday, February 23, 2024

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!

Monday, November 27, 2023

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

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!

Thursday, August 31, 2023

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!

Friday, August 18, 2023

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

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

Today I thought I'd share the first ten (of 20) strong suggestions I put together into slides for other Applied Clinical Informaticists, or those considering a career in Applied Clinical Informatics. I'm hoping this helps shed light on the importance and value of this role in modern healthcare, and how it helps to evaluate, implement, and maintain clinical technology and content. 

First, my #1 advice to newcomers - Always map the CURRENT-STATE and FUTURE-STATE workflows. While some might argue this is an unnecessary step, this exercise will benefit you in some very important ways : 

  • It will help you understand and relate to your end-users.
  • It will help you determine just how much work it takes to get from your CURRENT STATE (Point A) to your FUTURE STATE (Point B), which is necessary to help plan and allocate resources.
  • Finally, it will help you develop blueprints, develop downtime forms, identify stakeholders, and scope/prioritize your projects. 

Next, for my strong recommendation #2, I'd like to share how to write a good task, and then a good procedure. Learning to write a good task and procedure are so instrumental in building or untangling workflows, that it can even be used as a quick substitute for swimlane diagrams (e.g. when trying to quickly document a workflow during a video chat with clinical end-users) :

Strong recommendation #3 involves something that sounds dull, until you learn about how it impacts your infrastructure and operations - Document management. Learning how to create, edit, and archive documents can actually be a very powerful way of shaping or augmenting workflows in your electronic medical record. My mantra for newcomers : "Learn to control your documents, before they control you."

My next strong recommendation #4 is to learn the basic structure of healthcare operations, by understanding the relationship between Administrative, Academic, Research, and Clinical Enterprises (Note : Smaller community hospitals typically only have Academic and Clinical enterprises.In short : Administration supports the needs of the Academic, Research, and Clinical Enterprises. Learning how to navigate the people in these areas will help you break down silos, untangle workflows, and improve collaboration.

Coming in at #5 is my strong recommendation to care about hard work, details, and precision. "In Healthcare, there are no shortcuts." While timelines are often short, and there is often pressure to move ahead, try to resist the temptation to serve workflows that are not complete. (They may get you across your project finish line, but you risk having to do the whole project again, especially if end-users are not satisfied with the results.)

Strong Recommendation #6 might be a surprise to some : When working in a team, file naming conventions really matter. Group files should be both easy-to-find and easy-to-identify. My own personal favorite is :

DRAFT/FINAL - ARCHETYPE - Descriptor - Created/Updated/Approved mm-dd-yyyy.ext

Where : 

  • DRAFT / FINAL = Use DRAFT for documents in development, FINAL when approved
  • ARCHETYPE = Describes the file type (e.g. Education, Budget, Order Set, Catalog, Index, Contract, Policy, Protocol, Guideline, Schedule, Bylaws, Notes, Slide, Screenshot, etc.)
  • Descriptor = Describes a unique identifier for the file (e.g. "ICU DKA Treatment Discussion", "Meeting with Dr. Smith", "Malaria Workup", etc.)
  • Created/Updated/Approved = Use CREATED when first creating a file, UPDATED when updating a file, and APPROVED when creating a final version
  • mm-dd-yyyy = Describes when the file was created, updated, or approved
  • ext = File extension (e.g. ".docx" or ".PDF", etc.)

My next Strong Recommendation #7 is to learn the twenty-four (24) basic tools that shape all clinical workflows - Twelve (12) are typically outside of the electronic medical record, and the other twelve (12) are found inside the electronic medical record. Understanding the basic functions and design of each of these tools will help you to better plan projects, identify deliverables, identify stakeholders, and create smooth, complete clinical workflows : 

Coming in at #8 is my general recommendation to all Applied Clinical Informaticists to care about the entire 'Informatics tree', including both the 'Data In' and 'Data Out' branches. While most people will gravitate toward one area, understanding the whole tree will broaden your perspectives and skill sets, and overall help you plan workflows :

Strong Recommendation #9 for Applied Clinical Informaticists seeking to design smooth workflows comes from this 2015 blog post, where I recommend learning the relationship between concepts, terminology, templates, documents, and workflows. In general

  • Organizational Support (#8) is necessary to...
  • identify the concepts and ontologies (#7) that help you...
  • develop the definitions, terminology, and standards (#6) that you need to...
  • develop the templates and archetypes (#5) that will help you...
  • create the documents and tools (#4) that, combined, will help to...
  • create and support the workflows and processes (#3) that, if designed properly, will...
  • align with your goals and regulations (#2) which should...
  • align with your Mission and Vision (#1).

Typically, after first understanding #2, Applied Clinical Informaticists will concern themselves with aligning levels #7-#3 of this pyramid. (Learning how pyramid levels #8-5 impact the documents in #4 can help you troubleshoot even the most complicated workflows in #3.)

Finally, my Strong Recommendation #10 for Applied Clinical Informaticists seeking to design smooth workflow is to care deeply about change management. While Kotter's 8-step change management model is an excellent foundation, I recommend beginning with a standard, linear waterfall project model and then expanding it slightly for healthcare purposes, to include :

  1. Conception, Determination, and Documentation of Need for Change
  2. Evaluation, Analysis, Scoping, Presentation, Prioritization, and Approval for Change
  3. Project Planning
  4. Drafting of Change
  5. Building of Change
  6. Testing of Change
  7. Final Approval of Change (go / no-go discussion)
  8. Communication and Education of Change
  9. Implication / Publication ('Go-Live') of Change
  10. Monitoring and Support of Change

Once you have these ten steps laid out, you can begin looking at the tasks beneath each step, and developing your own 'waterfall-meets-healthcare'-type change management strategy.

I hope this is a helpful set of slides for newcomers to Applied Clinical Informatics. Feel free to leave comments below with any thoughts or feedback. In my next post, we will look at another ten (10) of my strong recommendations for Applied Clinical Informaticists seeking to design smooth workflows!

Have any helpful advice for newcomers to Applied Clinical Informatics? Are there any tips or tricks that were important to you? Please feel free to leave in the comments section below!