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!

Building your #Workflow Glossary

Hi fellow Clinical #Informatics and other #workflow enthusiasts, 

Happy 2019! While I continue to work on compiling the business case for Clinical Informatics, I thought I'd take a minute to talk about #workflow terminology. 

A. THE BACKGROUND :
Simply put - words matter. Any bilingual person who has ever tried to translate the phrase 'scram' or 'hit the road' into another language knows that a word-for-word translation does not always work. (Really? Hit the road..?) One might try to translate it as 'it's time to leave', but even that fails to convey the certain informal, vernacular quality that the phrase 'hit the road' conveys so well. So my advice to anyone working in a translational role - Do your best, but always translate at your own risk. 

In healthcare, we have a number of terms that people generally understand, but their exact definitions may vary from organization to organization. They include such common terms as : 

• Order
• Order Set
• Protocol
• Policy
• Procedure
• Guideline
• Standing Order
• Clinical Pathway
• Documentation
• Templates
• ... and more!

While almost all clinical staff have a general sense of these terms, their true understanding may not be exactly the same - And so, with regard to the term ‘protocol’, for instance, they may quietly have overlapping circles of a common understanding :

The problem is that these differences in understanding may result in dramatically different expectations about how exactly a 'protocol' works, and what it can do to help their workflow : 

• Can a protocol be used to allow a Registered Nurse to titrate an IV heparin drip?
• Can a protocol be used to allow a Registered Nurse to give a pneumonia vaccination?
• Can a protocol be used to allow a Respiratory Therapist to titrate the settings on a ventilator in the ICU?
• Can a protocol be used to allow a Registered Dietitian to modify a diet for an inpatient?
• What is the difference between a protocol and a standing order?

To increase the amount of common understanding, it's helpful to look at your federal and state regulations, along with your own safety and operational needs, to see if they offer any definitions that help clarify the answers to these questions :

After all, once there is a clear definition - then you can create a standardized template, development procedure, and staff education to give everyone on your team a greater, more standardized understanding of the tool and what it can do. Remember - It all starts with the definition.

B. THE PROBLEM :
Healthcare faces some challenges in harmonizing this terminology - What a protocol can do in some organizations is different than what a protocol can do in others. And despite CMS regulations which refer to the use of protocols, many federal and state regulations use these terms interchangeably - See this 2013 letter from the Centers for Medicaid Services (www.cms.gov), page 4 : 

Standing orders: Drugs and biologicals may be prepared and administered on the orders contained in pre-printed and electronic standing orders, order sets and protocols (collectively referred to as “standing orders” in our guidance) only if the standing orders meet the requirements of the medical records CoP.

And this, from the Interpretive Guidelines §482.24(c)(3) on page 78 : 

There is no standard definition of a “standing order” in the hospital community at large (77 FR 29055, May 16, 2012), but the terms “pre-printed standing orders,” “electronic standing orders,” “order sets,” and “protocols for patient orders” are various ways in which the term “standing orders” has been applied. For purposes of brevity, in our guidance we generally use the term “standing order(s)” to refer interchangeably to pre-printed and electronic standing orders, order sets, and protocols. However, we note that the lack of a standard definition for these terms and their interchangeable and indistinct use by hospitals and health care professionals may result in confusion regarding what is or is not subject to the requirements of §482.24(c)(3), particularly with respect to “order sets.” 

Making it even worse is when Informatics professionals then have to compare this with their state regulations :

... which may have slightly different understandings and definitions of these terms.

Fortunately, there are some very talented medicolegal and compliance experts out there, who can help an organization to develop a strategy for navigating these regulations, while planning their workflows, both before and after an EMR implementation. One of the best I've seen is Sue Dill Calloway, BSN MSN JD, who has a fantastic series of lectures on the importance of this terminology, for regulatory, financial, and patient safety reasons.

But in the absence of a simple, standardized national glossary, with good functional definitions of these tools - It can be very hard to develop the templates, development procedure, and education you need for your team. 

C. THE SOLUTION :
Given the lack of clarity about these terms, what's the average CMIO, CNIO, or clinical informaticist to do? Fortunately, there is a strategy you can employ, and that is expanding upon a fairly simple template for functional definitions : 

[ Term: What It's Called ] - [ Functional Definition: What It Does ] 

This simple template is helpful in separating terminology for tools that have slightly different functions, e.g. : 

Term1 - FunctionalDefinition1
Term2 - FunctionalDefinition2
 ...and so on...

So if we can accept this simple template for separating terminology and function, we can then start to draft a 'conceptual map' for these common terms in healthcare (click the image below to enlarge) : 

(REMEMBER - THIS GRID IS JUST A DRAFT AND IS NOT COMPLETE!)

As you start to do this exercise, you'll see that there are some terms which have very similar functions, and other terms which don't : 

• Guidelines and Policies initially look like they might have similar functions - until you consider that policies might result in root cause analysis and disciplinary action, and guidelines don't. (Policies=rules, guidelines=suggestions).
• Protocols and Standing Orders seem to have very similar functional definitions, so we need to figure out if they are true synonyms, or if there is some kind of a difference between them.
• Procedures and Plans also have similar definitions - So we will need to figure out how to separate them. In this case, I've taken the liberty of separating them in time, suggesting that procedures describe current tasks, and plans describe future tasks. 

Given the similarities between protocols and standing orders, it's helpful to separate them by considering their risk - and thus their initiation/triggering mechanisms, FOR EXAMPLE: 

• Standing Orders = Used for common, LOW-risk clinical scenarios in which the benefit to the patient of rapid evaluation and care outweighs any known risks. Standing orders may be initiated ('triggered') by a clinical POLICY (e.g. 'All clinic patients will be screened and potentially administered for pneumonia vaccination, according to the Standing Orders for Pneumonia Vaccination.) All orders and outcomes of standing orders will be attributed to the attending provider.
• Protocols = Used for common, HIGH-risk clinical scenarios in which the benefit to the patient of improved care standardization outweighs any known risks. All protocols must be initiated ('triggered') or discontinued by an ORDER (e.g. 'Initiate Ventilator Liberation Protocol' or 'Discontinue Ventilator Liberation Protocol'). All orders and outcomes of clinical protocols will be attributed to the ordering provider.

While you undergo this exercise, it's important to look at your regional, state, and federal regulations, and to speak to experts (like Sue Dill Calloway, BSN MSN JD as I mentioned above). If there are no regulations to guide you in this grid, then you and your clinical and administrative leadership will have to make local decisions about how your organization wants to define these tools.  

As you work on these definitions, keep in mind other things you can do to improve safety and clarity, e.g. "Orders are documented instructions [ that ] must be signed within 24 hours."

As you start to build out this grid for your own organization, talk to people who use these tools, and you'll start to better understand the form, function, and other issues related to their design. And once you think your grid is complete? Bring it back to your senior leadership for review, discussion, and formal approval. Voila! You now have your own organizational glossary that will help you develop the templates, procedures, and education that create a greater understanding, and improved standardization, predictability, and efficiency, for both your clinical and administrative teams. 

Hope this is helpful in guiding you to build your own workflow glossary! If you have any other tips, suggestions, or comments, leave them in the comments section below!

Remember - This blog is for educational discussions only. Do not use any of these definitions without formal review and discussion with your own informatics, legal, administrative, and clinical teams. Have any other clinical terminology tips you'd like to share? Feel free to leave in the comments below!