Clinical Informatics Memes

Hi fellow #ClinicalInformatics, #CMIO, #CNIO, #HealthIT, and other friends,

Explaining the term "Clinical Informatics" to laypeople is not easy. After first trying to describe the role, the discussion can get easily lost in the current sea-of-terminology surrounding the current use of the word "Informatics" - See the current Wikipedia entries on :

• "Informatics" : See https://en.wikipedia.org/wiki/Informatics (About 620+ edits since the first entry created 5/1/2006) 
• "Health Informatics (Biomedical Informatics)" : See https://en.wikipedia.org/wiki/Health_informatics (About 700+ edits since the first entry created 2/21/2010)
• "Clinical Informatics" : (According to Wikipedia, this is a subspecialty of Health Informatics above)

Shortly after I created this post, the famous Informatics teacher and guru Dr. Bill Hersh (from OHSU!) reviewed my diagram above, and offered his famous diagram from "A stimulus to define informatics and health information technology", published May 2009 in BMC Medical Information Decision Making, for comparison. 

So, from Hersh, W. A stimulus to define informatics and health information technology. BMC Med Inform Decis Mak 9, 24 (2009) doi:10.1186/1472-6947-9-24, the following diagram is being used with permission for educational purposes : 

Used with permission, from Hersh W. A stimulus to define informatics and health information technology, BMC Med Inform Decis Mak 9, 24 (2009)

(Side note : What an honor to get feedback from the great Dr. Hersh!)

Dr. Hersh correctly points out (paraphrasing) that all 'informaticists' need to care about standards, and both data in and data out - So drawing a distinction between people who focus on data in and others who focus on data out is not helpful. 

Still, my own personal observation is that some 'Informaticists' and 'Health Informaticists' seem to focus more on data in (Clinical Informatics), and others focus on data out (Analytics, Data Scientists, Research Informatics, Population Health, Public Health Informatics). Should we all work together? Absolutely, yes. Do we need to draw lines between roles? Ideally, no, but from a practical standpoint - It seems some people prefer to create data, and others prefer to analyze and study it. (Hopefully both types can work together for the betterment of individual and population health.)

Either way, while the common use of the term "Health Informatics" might lead some people to refer to themselves as "Informaticists" (Informaticians?) or maybe "Clinical Informaticists" (Clinical Informaticians?), there is often confusion about who is responsible for the difficult task of usability, configuration, testing, education, implementation, and support. 

After all, when it comes to data, garbage in, garbage out - so while analyzing data may be a powerful tool for analytics, research, and population health, the quality of that data is only as good as the usability of the software, the function of the configuration during patient care, the predictability of the clinical workflows, and the training support for the users.

Since none of this complex terminology and role discussion really helps laypeople to better understand the role of Clinical Informatics, or to engage physicians in the important role of configuration and adoption - I've decided to start assembling some Clinical Informatics memes, only for friendly discussion and educational purposes. 

They are attached below - Feel free to click each image to expand.

[ DRAFT ] LIBRARY - Sample Clinical Informatics Memes (click each image to enlarge) : 

 

 

I hope these images help you educate and engage with your own teams!

Remember, these images and this blog are for educational purposes only - Your mileage may vary. Always consult with your own clinical informatics team, legal/compliance team, and Clinical and Senior Leadership teams before engaging in any strategic planning or process changes.

Have any links to other educational graphics, or feedback you'd care to share? Feel free to leave them in the comments section below!

Shifting from Fire Fighting to Fire Prevention

Hi fellow CMIOs, CNIOs, Clinical Informatics friends, and other ClinicalJedi,

Happy holidays! One of my favorite things about working in the healthcare technology industry is meeting all of the other awesome Clinical Informatics professionals who are working hard to keep healthcare running electronically. If you're not already involved in it - The work is hard, and the hours are long. 

I recently had an informal meeting with a number of other Clinical Informatics professionals, and I had to share some thoughts about a great conversation we had as a group. It started with an informal discussion about the necessary 'care and feeding' of an EMR, e.g. : 

(a parody/tongue-in-cheek diagram, my apologies to Sea Monkeys)

... but eventually our informal talk progressed into a much more meaningful discussion : 

"Q: How can Healthcare IT shift from 'fire fighting' to 'fire prevention'?"

Great question! Across the industry, some of us are noticing that a number of people generally feel overwhelmed. Both inside and outside of Clinical IT, some people are  describing things like: 

• 'I don't feel like we can ever get enough done.'
• 'It's too hard to make decisions.'
• 'I come in planning to do A, but then find out we have to do B.'
• 'I just built this - but now it has to be changed again.'
• 'Why doesn't it just do what it's supposed to?'

These statements are all symptoms of a larger problem - Insufficient infrastructure to maintain your EMR. What do I mean by the infrastructure needed to maintain an EMR? I've never found much written about this, but generally I'm talking about things like : 

[ DRAFT ] LIST – Operational infrastructure needed for maintaining an EMR

www.dirkstanley.com (c) 2019 DirkMD

1. Clinical/Administrative Governance – Strategy for how to make synchronous organizational decisions that align clinical, administrative, IT, and sometimes research/educational stakeholders.
2. Data Governance – Strategy for how to define and standardize important concepts and terminology across the organization, formally review/approve requests for information, and use data/information as a strategic asset.
3. Terminology Management Strategy – Strategy for how to manage and standardize terminology, concepts, and hierarchies in your organization.
4. Policy Management Strategy – Strategy for how to draft, review, approve, modify, publish, and archive policy standards in your organization.
5. Document Management Strategy – Strategy for how to create, modify, and archive EMR-related (clinical) and non-EMR-related (administrative) documents in your organization.
6. Project Intake Strategy – Strategy for how to have a single point-of-entry to document and analyze project requests, with a preliminary project scope, risk evaluation, Return on Investment (ROI), Total Cost of Ownership (TCO), and other important factors BEFORE prioritization
7. Project Prioritization Strategy – Strategy for how to review, prioritize, and approve projects that have been analyzed during your project intake strategy (above).
8. Project Management Strategy - Strategy for how to manage small, medium, and large projects with routine and urgent priorities.
9. Design, Build, and Testing Strategies - Strategies for designing workflows, building workflows, and testing workflows (prior to education, implementation, and support)  
10. Change Management Strategy – Strategy for how to make workflow improvements/enhancements without significant disruptions to clinical care.
11. Change Control Strategy – Strategy for how to implement changes across both EMR-related and non-EMR-related environments, without disrupting other people/projects
12. Educational Strategy – Strategy for how to train clinical/administrative users of your EMR.
13. Communication Strategy – Strategy for how to communicate important items with the clinical/administrative users of your EMR.
14. Application Support Strategy - Strategy for how to provide elbow-to-elbow, help desk, and other application support for your users.
15. Content Management Strategy – Strategy for how to maintain the clinical content configured in your EMR (E.g. How will you update your order sets? Make formulary/payor updates? Manage urgent regulatory or safety issues?)
16. Business Continuity Strategy – Strategy for how to maintain clinical operations when your EMR is down for planned/unplanned downtimes.
17. Onboarding Strategy – Strategy for how to document and share information related to new clinical and administrative users for your EMR. (Often tied together with your credentialing process.)
18. Offboarding Strategy – Strategy for how to document and share information related to clinical and administrative users who are leaving your organization.
19. Reporting/Analytics Strategy - Strategy for reporting and analyzing information from your EMR, for departmental, organizational, local, and regional purposes.
20. Patient Portal/Engagement Strategy - Strategy for engaging patients and releasing information to your patient portal.
21. Provider Engagement Strategy - Strategy for engaging clinical staff (Physicians, Nurses, Advanced Practice Providers, and other clinical staff) in workflow discussions and EMR-related projects.
22. Technology Procurement Strategy - Strategy for managing technology purchases (both hardware and software), to help ensure the implementation cost and total cost of ownership are both understood before purchase
23. Practice Procurement Strategy - Strategy for procuring new practices (e.g. those that want to join your network), to convert over their data, terminology, and practices to meet the needs of your organization. 

 ... and more. 

These are all important parts of maintaining a healthy EMR, and many organizations already have a lot of these pieces in place - but they are usually not an area of intense focus until an organization becomes more mature with their understanding of technology. Unfortunately, until then, the environment can feel a bit chaotic and unstable. This is all part of the road from implementation, to stabilization, to optimization. 

This is one of the reasons why it's important to acknowledge that the CIO, CMIO, CNIO, Clinical Informatics, and Health IT staff need to focus on more than just what's inside the EMR - The processes and tools outside the EMR are just as important as the ones inside the EMR. If they do not have influence over those tools and processes outside the EMR, then they cannot align expectations with EMR configurations, and user satisfaction and productivity will drop. 

As it's often been said - Clinical Informatics technically has nothing to do with technology. It is more about information architecture, the processes external to the EMR, and how they impact the configurations inside the medical record. The same work would apply in a hospital with a paper record - Only, as we know, paper is more forgiving about workflow inconsistencies, so the need for this infrastructure is not as great. (Metaphorically, paper is like building with marshmallows, and EMRs are like building with bricks.)

So as a CMIO, about half of my work is managing expectations and configurations inside the EMR, and half of it is working on these sorts of external infrastructure enhancements. 

"A: Strategic Planning."

If having this infrastructure in place helps prevent 'fire fighting' (E.g. Frustrated users, slow projects, unanticipated outcomes, workflow inconsistencies, rebuilds, etc.) - Then the simple strategic initiative needs to come from a gradual focus on fire prevention strategies (e.g. building this infrastructure).

It can be hard to do this when resources are tight, but it starts with strategic planning - making a 6-month, 12-month, and 18-month strategic plan - E.g. :

[ DRAFT ] PLAN - Sample strategic plan to build EMR infrastructure 
www.dirkstanley.com (c) 2019 DirkMD

• Next 6 months - Will spend 4 hours a week on infrastructure enhancements ('fire-prevention' strategies)
• 6 - 12 months - Will spend 8 hours a week on infrastructure enhancements ('fire-prevention' strategies)
• 12-18 months - Will spend 12 hours a week on infrastructure enhancements ('fire-prevention' strategies)

Alternatively, if you have additional resources available, it could be helpful to have a separate team to focus only on developing infrastructure, so that your internal resources are not disrupted from the routine day-to-day activities needed to keep your system operational.

Either way, I believe that fire prevention is always more cost-effective than fire-fighting, and will help you to better realize the potential benefits of your EMR - so if you need help developing this infrastructure, I believe the investment is well-worth it.

Hope this helps you develop your own strategy for stabilizing and optimizing your EMR. Remember, half of the work is inside your EMR, and half of it is outside. 

Have any tips for developing infrastructure or stabilization/optimization strategies? Feel free to leave in the comments section below!

Remember, the above is for educational discussion only - Your mileage may vary. Always review with your operational, legal/compliance, IT, Clinical Informatics, and Senior Leadership before undertaking any of these discussions in your own organization.

My Clinical Workflow Design Glossary

Hi fellow HealthIT and Clinical Informatics friends,

Sometimes people ask me about how I learned workflow design, and where I learned to quickly spot workflow problems.

After a few years of trial-and-error early in my career, and learning from a lot of other clinical informatics leaders in the field, I'm happy to share that good workflow design starts with this: Definitions.

Definitions are the lifeblood of any clinical informatics professional. They answer two very important questions : What is it called, and what does it do? When you define something, you are clarifying both its form and its function. 

So when I design (draft!) my own workflows, or workflows for other clinical staff - what are the things I define, and how do I define them? Adapted from my recent post and my 2015 post on The Informatics Domain and Workflow Management, I usually start off with the 24 most common tools found in modern Healthcare: 

A. Tools typically found OUTSIDE an EMR : 

1. Plans (Project, Drafting, Building, Testing, Communication, Education, Go-Live, and Support/Monitoring)
2. Policies/Procedures
3. Guidelines
4. Protocols
5. Patient Consents
6. Interfaces
7. Staff / Patient Education Modules
8. Committee Charters
9. Org Charts
10. Budgets
11. Job Titles/Descriptions
12. Staff Schedules

 B. Tools typically found INSIDE an EMR :

1. Registration Information
2. Clinical Documentation (Notes, Flowsheets, videos, audio, other media)
3. Labs/Pathology
4. Radiology/Images
5. Orders
6. Order Panels / Order Sets / Clinical Pathways
7. Medical Logic Modules (MLMs)
8. Clinical Decision Support (Best Practice Alerts (BPAs), Infobuttons, etc.)
9. Security Groups / Profiles / Filters
10. Reports/Dashboards
11. Charges
12. Patient Schedules

From here, we can break out a few terms, alphabetize them, and start to create a basic workflow design glossary :

[ DRAFT ] GLOSSARY - The DirkMD Workflow Design Glossary
(c) 2019 DirkMD www.dirkstanley.com

1. Budget - A tool used to document and allocate future resources for a person, group, team, division, organization, or project
2. Charge - Tools to create bills for services
3. Clinical Decision Support (Best Practice Alerts (BPAs), Infobuttons, etc.) - Tools used to guide or force clinical staff into institutionally-defined best practices
4. Clinical Documentation (Notes, Flowsheets, videos, audio, other media) - Documents used to record patient history, activities, status, and/or plans at a given date and time.
5. Clinical Pathway - A collection of order sets used to standardize care for a defined condition or procedure.
6. Charter (Committee/Team Charter) - Tools used to define the leadership, membership, mission, responsibilities, meeting frequency, measures of success, delegated authorities, quorum, and other information related to a team or committee
7. Consent (Patient/caregiver consent) - Tools used to document patient/caregiver understanding of the risks/benefits of a procedure
8. Dashboard - A collection of regularly- or continuously-updated reports used to routinely monitor a function or functions.
9. Document - A tool used to record and transmit information 
10. Education Module, Staff - Tools used to educate staff, using the institutionally-accepted language, about a topic or topics.
11. Education Module, Patient/Caregiver - Tools used to educate patients or caregivers, in their language, about a topic or topics.
12. Guideline - A tool used to educate staff about best practices to achieve a desired outcome
13. Interface - A tool used to securely transmit information between systems
14. Job Title/Description - Tools used to align a job role and responsibilities
15. Labs/Pathology - Tools used to document results of a laboratory or pathology study
16. Medical Logic Modules (MLMs) - Custom programming tools to electronically link two workflows
17. Medical Record, Legal - The collection of clinical information related to a single patient that is routinely released to the patient, caregiver, and legal authorities upon request.
18. Medical Record, Business (Comprehensive Record) - The total collection of clinical information related to a single patient, including the legal medical record, metadata, and other information.
19. Order (aka 'prescription') - A tool used to document clear and well-defined instructions to deliver a defined type of patient care to a defined patient with a defined priority at a defined date/time with a defined duration in a defined manner, sometimes for a defined indication.
20. Order Panel - A collection of orders with related functions which are used to standardize a common clinical function across a specialty or specialties, often with the intent of building into order set(s) (see below).
21. Order Set - A collection of orders (and order panels) used to standardize and expedite the ordering process for a common, well-defined clinical scenario. 
22. Org Charts - Tools used to define an organizational structure or reporting hierarchy.
23. Patient Schedules - Tools used to define the planned date/time and duration of patient care. 
24. Preference Lists ('Pick Lists') - Collections of commonly-used orders based on frequency of use, for a variety of purposes with no clearly-defined or designed scenario or function. 
25. Plans (Project, Drafting, Building, Testing, Communication, Education, Go-Live, and Support/Monitoring) - Tools used to document and organize resources and activities needed for a future project or desired outcome
26. Policies - A tool used to document and define an organizational standard 
27. Procedures (aka 'Workflow', 'Recipe', or 'Algorithm') - A collection of ordered TASKS (see below) that uses people, time, and resources to achieve a defined goal.
28. Protocols, Clinical - A tool used to automate and standardize a clinical process by documenting the delegation of order management responsibility to a registered and trained member of the patient care team.
29. Protocols, Chemotherapy - A tool used to plan chemotherapy delivery and monitoring for a defined type of cancer.
30. Radiology/Images - Tools used to display radiologic and other patient care still and video images and their interpretations. 
31. Registration Information - Tools used to legally identify a patient, their address, their contact information, their payor information, and their emergency contacts.
32. Reports - Tools used to display requested information related to a requested function or activity. 
33. Staff Schedules - Tools used to define who is responsible for a patient care service at a defined date/time.
34. Security Groups / Profiles / Filters - Tools used to allow or restrict access to a part (or parts) of the patient record
35. TASK - The most granular unit of work, may be written as [WHO] will/may [WHAT] {how} {where} {when} {why}, where : 

• [WHO] - Required field, describing who will perform the task 
• will/may - Required field, use WILL for mandatory tasks, MAY for optional tasks
• [WHAT] - Required field, describing the expected task{how} - Optional field, use only for clarity, describes how to perform the task
• {where} - Optional field, use only for clarity, describes where to perform the task
• {when} - Optional field, use only for clarity, describes when to perform the task 
• {why} - Optional field, use only for clarity, describes why to perform the task

This is a pretty decent start, and while it's only a [DRAFT], it fortunately includes a number of terms that are not currently well-defined or published by any of the major regulatory or healthcare standards agencies.

So with this glossary above, what advice do I give people trying to build workflows?

1. Start with documenting your procedures (workflows), using the template outlined in the above definition of TASK. (You can also use flowcharting/swimlane diagrams, but I find this method to be faster, easier to train, and less prone to error.) Both your current-state and future-state workflows will be key to understanding what kind of tools, time, people, and resources you will need to get from Point A to Point B.
2. Determine which tool(s), both inside and outside the EMR you will need to support your future-state procedure (workflow). Most clinical workflows depend on a combination of tools, from both inside the EMR and outside the EMR. You can almost take the above glossary, and circle the tool(s) you will need to get from Point A to Point B, to create a list of project deliverables.
3. Draft those tools. Review your current-state workflows with your end-users, and use them to build your future-state workflows. Get their input as you draft your new tools, both inside and outside the EMR. 
4. Build those tools. Once your end-users approve the drafted tools, you can bring them to IT, policy writers, finance, and other administrative users to build the final tools you will need to support your new future-state workflow.
5. Test those tools. There are four types of testing you'll want to consider. If they are inside the EMR, they may need more testing than those outside the EMR, but generally they include : Unit testing (to make sure each design piece functions as expected), Integrated Testing (to make sure the pieces work together as expected), Regression Testing (to make sure the pieces work together as expected with other pre-existing tools in the setting they are expected to function in), and End-User Acceptance Testing (to make sure the end-users can use the tools to perform the expected tasks). 
6. Communicate and Educate (Train) those tools. Let your clinical and administrative users know about the clinical (inside EMR) and administrative (outside EMR) tools you will need to support your new workflow(s), and show them how to use them in anticipation of your defined go-live date.
7. Deliver / Implement those tools. Deliver both the clinical (inside EMR) tools and administrative (outside EMR) tools at the expected implementation (go-live) date.
8. Support and monitor those tools. Make sure you have a plan for how to support end-users, and monitor the effectiveness and their ability to use your new tools, both inside the EMR and outside the EMR, to support the desired workflow(s). 

I hope this helps demystify the workflow design process, which is tightly interwoven with the definitions for both clinical and administrative tools, and baked into your project (and change) management strategies. 

Remember this page is for educational discussion only! Do not use any of the above definitions or procedures for professional purposes, without the approval of your clinical informatics, legal, operational, and senior leadership.

Have any other definitions or workflow design principles you'd like to share, or other comments/feedback? Please leave your thoughts in the comments box below!

Blueprints Before Build

Hi fellow CMIOs, CNIOs, HealthIT, and Clinical Informatics friends,

I'm writing today to talk about burnout, or what's also sometimes referred to as "moral injury".  

In the bigger discussion about healthcare reform, burnout is a hot topic, largely because of the multiple problems it's causing. A number of physicians are leaving the medical field, usually after about 10-15 years in practice, to find non-clinical jobs. 

And it's not just physicians - Nurses, pharmacists, and other clinical staff are feeling the same way. Healthcare is becoming 'too much'. 

When clinical staff leave either their position, or the field entirely, this creates problems for everyone : 

• There is the personal (emotional and sometimes physical/financial) injury to the provider/nurse/pharmacist themselves (and their family)
• There is the replacement cost for that provider/nurse/pharmacist, including a recruiting cost, credentialing/onboarding cost, and training cost, which industry estimates show, together, can cost over $50-$75k to replace a provider.
• There is the industry loss of a talented and hard-working clinical staff member, one that could be helping to care for patients as our country ages and the demand for providers in the next ten years goes up.

I know this topic well because, as a physician, I've been there myself, and personally understand the pain of bad workflows. This is one of the reason I blog about clinical workflow design. While the EMR is often maligned for its contributions to provider burnout, I'd like to share a deeper clinical informatics understanding of where these workflow issues can stem from. 

A. WHAT IS WORKFLOW?

I usually tell people - Workflow is a lot like carbon monoxide. It's silent, invisible, and odorless, but if you don't know about it, it can kill you. 

When discussing workflow with clinical staff, I often get questions like : 

• By workflow, do you mean the way this button in the EMR makes this window open?
• By workflow, do you mean the registration policies of the organization?
• By workflow, do you mean the documentation policies, that are often shaped by payor/insurers?

Workflow is all of the above. 

I've shared this once before, but one of the most well-known leaders in the national discussion about clinical workflow and Business Process Management (BPM) is Charles Webster, MD ( Twitter : @wareflo ) who in 2016 offered this great definition of workflow in his post, "Task workflow and interoperability definitions: Pragmatic interoperability part 2" : 

"Workflow is a series of tasks, consuming resources, achieving goals."

When I train people on workflow design, I usually offer a slightly different definition, that I think still fits with Dr. Webster's definition above, but has a few small distinctions. My definition is below : 

"Workflow is a series of ordered tasks that uses people, time, and resources to achieve a desired goal."

I expanded the definition because I feel it's important to show the relationship between workflow and another important definition - procedures. From Google's definition of procedure : 

What you start to see is that workflows and procedures are, largely, the same thing - They are both essentially your 'recipe for getting things done'. 

How exactly does a healthcare organization get things done? This is an interesting topic. Healthcare operations is a complex dance between people (staff) and their environments. People often think of the EMR as the sole purveyor of workflow issues, but environments and clinical workflows are actually shaped by tools both inside and outside of the EMR : 

Experienced Clinical Informatics professionals know that, when analyzing and fixing workflows, that half of the work is inside the EMR, and half of it is outside the EMR. Alternatively, it's easy to create workflow inconsistencies by only focusing on the tools inside the EMR, or only focusing on the tools outside the EMR. Good workflow depends on synchronizing the tools on both sides of this technology fence. 

B. WHAT IS 'BAD WORKFLOW'?

Bad workflow feels inconsistent. As I started to explain above, bad workflow happens when the procedures of an organization don't fit as seamlessly as they could or should. Especially in healthcare, this can be difficult to manage, since patient care depends on the timely delivery of quality care, 24/7, no holidays or exceptions. In most industries, a 2-hour delay or downtime is tolerable. In healthcare, it is not. 

Bad or incomplete workflow is not easy to find electronically or on paper, but it's easy to spot through clinical staff interviews, or just listening to conversations. Some clinical staff understand workflows enough to recognize workflow issues (and complain about them), but more often you will hear statements like : 

• "Who made that decision?"
• "Why does it take so long to get things done?"
• "Why is it so hard to do the right thing?"
• "I can't keep up."
• "I stay after my shift to get things done."
• "I'm constantly getting paged." (or, "I'm constantly having to page the doctors.")

These are all symptoms of problematic or incomplete workflows. If it takes more than one phone call to schedule a patient, or more than one order to obtain a medication, lots of clicks to get through an order set, or lots of extra documentation to ensure reimbursement from a payor - These are all signs of workflow problems. 

Because so few people talk about workflow design, it's easy to unknowingly create workflow issues by either : 

• Only focusing on tools inside the EMR, or only focusing on tools outside the EMR (as described above)
• Incompletely addressing the workflow (e.g. Only having 80% of the orders needed to admit a patient in your admission order set.)
• Some combination of the above.

C. WHAT IS 'GOOD WORKFLOW'?

Good workflow just feels right. It gives clinical and administrative staff confidence that the right thing is happening. It feels like someone with your specialty configured your EMR, wrote your policies, and trained you. I've even heard it described as a 'leisurely walk down a street, where the things you need pop up in front of you just when you need them - not before, and not after.'

Technically speaking, good workflow means : 

• All of your tools, both inside and outside the EMR, support the same good, evidence-based, best-practice, efficient, and user-friendly workflows. 
• The workflows are completely built out. (Note : Incomplete workflows generate extra telephone calls and pages!!) 

Generating consistently smooth and complete workflows can be difficult, due to the large number of stakeholders that all healthcare organizations have to interact with, all of whom have an impact on the local workflows and configuration : 

Again, it's important to remember that configuration isn't just the tools inside the EMR - The tools outside the EMR are just as important, and should be roughly half of the deliverables of any clinical workflow project.

D. HOW TO BUILD 'GOOD WORKFLOW' 

Building good, smooth, and user-friendly clinical workflows consistently requires strategy, planning, and infrastructure. 

First, you'll want to propose a consistent change-management process, one that has a single point-of-entry (intake process), and follows all the way through to delivery of services and the monitoring and support required after your implementation. I recently started the Twitter hashtag #Blueprintsbeforebuild to try to create awareness of the importance of this change management process : 

The above process shows the sort of rigor and discipline that's needed to help ensure all of the current- and future-state workflows are well-understood, best-practice, cost-effective, and planned for - and that all of the stakeholders and deliverables have been properly identified during the project planning stage. 

Next, you'll need leadership support for this change management process, as well as agreement, both inside and outside of IT, to use the new process - as well as agreement on how to address complex project management situations like urgent or emergent projects that come up from time-to-time.

You'll also need governance, to help balance the needs of the many stakeholders who play a role in shaping your configuration and your workflows, and prioritize projects after they have been properly evaluated, analyzed, and scoped. 

Finally, you'll need a good project intake process, one that helps your directors to submit projects that get evaluated, analyzed, and scoped in a timely basis, before they get prioritized by your agreed-upon governance and leadership.

E. CONCLUSION

If the above seems complicated, you're right - It is a lot of work. Clinical Informatics professionals are constantly working on building out this sort of governance, prioritization, change management, and project management, all with the goal of delivering smoother and more complete configurations (both inside and outside the EMR), that then help improve workflows, and : 

• Increase stakeholder engagement
• Increase provider satisfaction
• Reduce variation in practice
• Increase consistency
• Increase quality of care
• Reduce clicks
• Reduce unnecessary pages / phone calls
• Reduce training time
• Reduce burnout

You can start by asking your Clinical Informatics team about your current- and future-state workflows, supporting them in these important operational discussions, and sharing your knowledge about the relationship between good change management, solid governance, great configuration (both inside and outside the EMR), and great workflow - the kind that makes both clinical and administrative users smile. :-)

Remember, this discussion is for educational purposes only - Your mileage may vary. Always check with your clinical leadership, legal team, and clinical informatics leadership, before you consider any changes to your change management strategy. 

Have any project management or change management tips to share? Feel free to leave them in the comments below!