Sunday, December 8, 2019

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
  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) - Tools used to record patient history, status, and/or plans
  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 continuously- or regularly-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 what patient care 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!


Monday, December 2, 2019

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/financialinjury to the provider/nurse/pharmacist themselves (and their family)
  • There is the replacement cost for that provider/nurse/pharmacist, including a recruiting costcredentialing/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. 


I usually tell people - Workflow is a lot like carbon monoxide. It's silentinvisible, 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 EMRGood workflow depends on synchronizing the tools on both sides of this technology fence. 


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.


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.


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.


If the above seems complicated, you're right - It is a lot of workClinical 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 governancegreat 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! 

Thursday, November 7, 2019

Very funny IT video

Hi fellow HealthIT and Clinical Informatics friends,

I'm taking a break from my usual educational pieces, just had to share this hilarious video someone sent me from YouTube. If you've ever worked in HealthIT, you'll appreciate it:

Adapted from Jesus Quintero's show in Spain, adding the IT subtitles gives it a whole new life!

Hope you enjoyed it!

- Dirk :)

Wednesday, October 30, 2019

Intro to CPOE and Order Sets

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

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

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

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

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

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

Wednesday, August 28, 2019

Improving EMR Satisfaction by Better Anticipating Clinical Needs

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

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

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

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

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

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

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

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

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

Let's start by looking at what exactly is a "Doctor" (Physician).
Note that the supervision model above requires a number of workflow configurations in an EMR - Most commonly, with orders and clinical documentation (notes) - 
  • Which order(s) WILL require an attending countersignature?
  • Which order(s) will NOT require an attending countersignature?
  • Which note(s) WILL require an attending countersignature?
  • Which note(s) will NOT require an attending countersignature?
  • Knowing the EMR will function differently for Residents, Fellows, and Attendings - How will the EMR be configured for Fellows who sometimes moonlight as Attending providers?
In addition to a clear understanding of these roles, responsibilities, and configuration differences - It's also important that an organization have an easy way of knowing when doctors change their roles. (July 1st is not a guarantee that a doctor's clinical role will change!)

With the expansion of medical technology and clinical specialties in the 1970s and 1980s, came a new set of providers who could help 'extend' the reach of the attending physician, including Advanced Practice Providers (APPs) such as : 
These roles also have unique EMR configuration and training needs, which are highly dependent on the supervision needs, which often depend on state regulations. Like Doctors/Physicians, having a clear understanding of these clinical roles and their supervision needs is key in providing the proper configuration, security, and training. 

So to put this all together, we can now represent the Doctors (Resident, Fellow, and Attending Physicians) and Advanced Practice Providers (APPs) as a common set of Providers (Prescribers), each with a DEA number and prescriptive authority, but with different supervision needs and expectations
Again, this catch-all term can be helpful, especially for pharmacies that want to provide services to all of these roles. It's not as helpful in legal/billing scenarios, where usually the Supervising Attending Provider (1c) (and sometimes the independent APRN!) are more commonly the focus of discussion.

So we've discussed how these clinical roles impact EMR security, configuration, and training. What other questions can you ask, to better anticipate a user's clinical needs, configuration needs, and training needs? While it may not be comprehensive, I recently drafted this list of questions you might ask a provider during on-boarding and credentialing, to better understand and anticipate their clinical, academic, research, and administrative needs:  
Again, this list of questions may not be comprehensive, but it helps show how good credentialing and provider on-boarding can help HealthIT people to better understand a user's clinical, administrative, research, and academic roles, and anticipate the specific needs for each role. 

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

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

Friday, August 9, 2019

What exactly does "Inpatient" mean?

Hi fellow CMIOs, CNIOs, Clinical Operations, HIM, and other Clinical Informatics leaders,

I'm constantly amazed by the complexity of medical terminology. A lot of unnecessary heartache comes from the unappreciated differences in understanding between different parts of the clinical care team and other billing/administrative stakeholders.

In modern healthcare, there are a few words which can trigger a special level of confusion, and surprisingly one of them is the word "inpatient". It is one of the most context-sensitive, role-dependent words that I can think of, commonly used across the table in healthcare operational and workflow discussions. 

What exactly does it mean, how does it work, and how can it be misunderstood?

1. THE HISTORY      

While I'm not an expert medical historian, the history of the word "inpatient" likely derives from the 200-or-so-year history of healthcare. Most hospitals were not really hospitals like we think of them today - They were charity and alms houses, often with beds, with nuns, nurses, and practitioners/physicians tending to sick and dying patients in them.

In a local nearby community hospital, where I once worked, I once interviewed some older nurses who volunteered in our coffee shop - Just to ask them what they remember about the history of the hospital. (For those of you who are lucky enough, ask some older nurses about the history of healthcare - The stories they tell are unbelievable!)

What I found out is that our hospital was once, back in the late 1800s, a simple house, on a hill, donated by a local farmer to help tend to the sick in our area. "It was a place where old and sick farmers came to die," they explained to me. "And then, one day, penicillin arrived - And suddenly, the farmers didn't die, but actually felt better and wanted to go home." And voila - The discharge process was born. 

Taking care of these patients, 24/7, inside the 'house' took a lot of work and attention. Unfortunately, the local community physicians weren't available 24/7 (many had families!), so how exactly did they care for patients 24/7 when there were no physicians available?

In most academic hospitals, there were younger student doctors, who as part of their training agreed to basically live "in" the house - Hence, the name "Residents", since during training they were basically committed to living inside the house, while the Attending providers went home at night to their families.  

Meanwhile, in many community hospitals, this was probably a complex situation for the nurses, who fought heroic battles to keep their patients alive and comfortable until the morning, when the community providers would return and do morning rounds in the hospital. Remember, it was the 1990s when Hospitalist medicine was born, so before that - I can only imagine it must have been a difficult situation for nurses who fought for their sickest patients. (If you know any nurses from this era, make sure you appreciate them.)

In any case, from this era of healthcare, came two important concepts : 

  • "Inpatient" - Patients INSIDE the 'house'/hospital
  • "Outpatient" - Patients OUTSIDE  the 'house'/hospital

During this era, this terminology was probably somewhat helpful in judging patient acuity, e.g.:
  • If you were sick enough to need to be in a hospital --> INPATIENT
  • If you weren't, and could walk around --> OUTPATIENT
And so, healthcare appears to have made it through the 1960s-1970s with those terms mostly intact. 

In the 1960s and 1970s, with increased technology, specialization, and standards, the price of healthcare increased. Eventually payment reform became necessary to help control the costs of this care. 

So to help better understand patient acuity and care needs, two terms became important - Taken from is this : 
  • "LEVEL OF CARE" - The intensity of effort required to diagnose, treat, preserve, or maintain an individual's physical or emotional status
  • "LEVEL OF SERVICE" - Based on the patient's condition and the needed level of care, used to identify and verify that the patient is receiving care at the appropriate level.
So these terms were stratified to help better organize our healthcare system. In general : 
Looking at the above list, one might ask, "Why is the Emergency Department considered an outpatient level-of-care/acuity? Don't they have really sick patients?" The answer is yes, they often do have sick patients - But :
  • because the modern-day Emergency Department grew (circa 1960s-1970s) out of what was once a combination of primary care, urgent care, and the historical "Accident Room" in most hospitals, AND
  • because many of the patients seen in an Emergency room are treated, fixed, and sent home
  • because patients in the ED are usually waiting to be admitted to inpatient levels-of-care/locations
... the Emergency Department is kind of an unusual hybrid patient care location, staffed with critical care-trained doctors and nurses, but is still considered an outpatient patient care location (even when they have patients with inpatient acuity needing an inpatient level-of-care).

And with regard to nurse training and staffing? Generally, nurses train and staff uniquely in each of these levels-of-care. (Interesting note : Staffing usually depends on the routine vitals!)

And finally, with regard to "bed" management? 
  • INPATIENT BEDS = A bed with a patient assigned to one of the inpatient levels-of-care, usually (but not always!) geographically located in an inpatient area*
  • OUTPATIENT BEDS = A bed with a patient assigned to one of the outpatient levels-of-care, usually (but not always!) geographically located in an outpatient area*
* NOTE - In "bed overflow" situations, it's entirely possible to "make" an "Inpatient" bed in a geographically "outpatient" location - E.g. A patient waiting for an inpatient intermediate/cardiac bed might be physically lying in a bed in an outpatient/ED location, but if they are admitted to the inpatient intermediate/cardiac level-of-care, they are still considered to be an inpatient, in an inpatient bed, "boarding" in the ED/outpatient location.
So this level-of-care index was at least a little more helpful in roughly estimating a patient's acuity, and for planning the kind of care that would need to be delivered in these locations.

With these newer, better-defined levels-of-care, some providers started to distinguish themselves and their clinical practices : 
  • "I do inpatient medicine."
  • "I do outpatient medicine."
  • "I do inpatient neurology."
  • "I do outpatient neurology."
  • "I do inpatient hospitalist work."
  • "I do inpatient pulmonary and critical care."
  • Etc...
And so physicians started to define and stratify themselves - again with the curious hybrid of the Emergency Department, where modern ED providers have critical care training but are still considered to be working in an outpatient location, hence, are technically outpatient providers.

Once upon a time, the terminology was pretty simple : 
  • ADMITTED = Admitted to an inpatient level-of-care / location
  • NOT ADMITTED = Not admitted to an inpatient level-of-care / location
But as the price of healthcare continued to rise in the 1980s, this was too granular a concept, and some payors started to question whether everyone in the hospital really needed to be admitted to the hospital - Did they all need to be inpatients? (Were they all really that sick?)

So again, new terminology was developed, to help distinguish : 
  • "INPATIENT" - Patients who are admitted to an inpatient level-of-care/location, and sick enough to need to stay in the hospital for at least two midnights (E.g. The "sick" sepsis patient with multiple organ failure)
  • "OBSERVATION/OUTPATIENT" - Patients who are admitted to an inpatient level-of-care/location, but not sick enough to require a stay in the hospital for more than two midnights. (E.g. the long-distance runner who got dehydrated and dizzy, and just needed a night of IV fluids and observation before being sent home)
Unfortunately, the use of the billing status "INPATIENT" can be easily confused with the level-of-care/location "INPATIENT".

5. THE SUMMARY       
So it's entirely possible to have : 
  • An admitted inpatient with 
  • a CMS billing status = OBSERVATION/OUTPATIENT
  • being cared for in BED/LEVEL-OF-CARE = INPATIENT(MED/SURG),
  • temporarily boarded in a LOCATION = OUTPATIENT(ED),
  • until they arrive in their final LOCATION = INPATIENT(MED/SURG UNIT),
  • being routinely cared for by their INPATIENT HOSPITALIST or
  • being emergently cared for their OUTPATIENT ED PROVIDER (e.g. during a code?)
And during that emergency code, the OUTPATIENT ED PROVIDER may come to work on the INPATIENT (currently in OBSERVATION status) in an INPATIENT LEVEL-OF-CARE/ACUITY and in an INPATIENT LOCATION, along with nurses trained to deliver inpatient care

And after the code, if the patient is sick and is estimated to require more than 2 midnights of care in the hospital - the INPATIENT HOSPITALIST may ask the Case Manager to change their CMS Billing Status from OBSERVATION/OUTPATIENT to INPATIENT

Makes perfect sense, right? It can be complicated! Unfortunately, our healthcare system is somewhat limited by the lack of terminology development, so I thought I'd summarize it here : 

Hope this helps! Need help interpreting or translating during discussions? Ask your own Clinical Informatics, Health Information Management, or other Clinical Operational leadership for help!

Remember, this blog is for educational purposes only - Your mileage may vary. Have any stories to share about translating this terminology? Have ideas of how to simplify? Feel free to leave in the comments below!

Tuesday, July 9, 2019

Why You Should Always Map the Current State

Hi fellow CMIOs, CNIOs, #Informatics, and other #HealthIT leaders,

Today I'm writing to discuss a fairly common question in clinical change management, related to the practice of 'mapping the current state': Is it really necessary?

When planning a clinical improvement project, it may be one of the most common newbie mistakes: Thinking you can't, or don't need to analyze the current state : 

It has been said that Clinical #Informatics and #workflow engineering is a bit like 'rebuilding the plane while it is still in the air' - Healthcare is in business 24x7, and can't really shut down, even for a few minutes, without a potential impact on patient care. (This is one of the things that separates #HealthIT from #BusinessIT, #AcademicIT, and #ResearchIT.)

So in today's fast-paced healthcare environment, it's more important than ever to make sure that projects are executed well, on-time, on-budget, and according to plan. And this is where our discussion starts : How to make sure you're really planning well

First - Without mapping the current state, it looks something like this : 

... and then it becomes impossible to tell if your project is going to look like this : 

... or this...

... and so without a current-state assessment, it's easier to either under- or over-estimate the work it will require to get to Point B. 

Remember, smooth workflow change is not just about the configuration you need to do inside the EMR - It's the work you need to do outside of the EMR too, including development of staff education needed to get your clinical teams from Point A to Point B - See #7 in the grey box on the left-handed side below : 
Taken from my 11-18-2015 blog post, 

Again, in today's healthcare environment, having smooth, well-executed workflows and projects is more important than ever. As an example, Dr. Danielle Ofri recently wrote this very relevant opinion piece in the New York Times which really introduces the importance of well-designed, well-planned workflows :

(June 8th, 2019)

... in which she writes, "With mergers and streamlining, [corporate medicine] has pushed the productivity numbers about as far as they can go." After she describes some real problems with the efficiency of some EMR documentation, she shares this insight, "But in health care there is a wondrous elasticity - you can keep adding work and magically it all somehow gets done."

While Dr. Ofri is quite right that this is a commonly-held belief, there's still a basic problem: Math is math. Healthcare should not plan to do 25 minutes of work in a 15 minute timeframe. So in the national discussion about physician burnout (#physicianburnout, or as ZDoggMD describes it, 'moral injury'), it's more important than ever to make sure workflows serve the needs of the patients, providers, nurses, pharmacists, and other clinical and administrative people working in #healthcare. To make sure we're not overloading our clinical teams, every data element needs to be well-analyzed, well-studied, well-planned, and serve a legitimate patient care or business function.

And this is why the current state is important. Without studying the current state, it becomes very challenging to answer questions like: 
  • Which stakeholders need to be involved in this project?
  • How much time will this project take?
  • What training and support will we need to go-live with the planned future state?
Still, some people express concern about the work it takes to map the current state, or question the real benefits. Allow me to share some common arguments, along with my counter-arguments
ARGUMENT : "We don't have time or resources to map the current state." 
COUNTER-ARGUMENT : "Will we have time or resources to fix things that we didn't account for? How will we know the scope of the effort, who to invite to meetings, or how much educational effort we will need to plan for?" 
ARGUMENT : "It's not worth mapping the current state, last time it took us hours and we still couldn't figure it out." 
COUNTER-ARGUMENT : "Not being able to map the current state, despite best efforts, is still a really important factor to consider when scoping and planning a project." 
ARGUMENT : "We don't want to map the current state because we don't want to bring old habits into our new workflow." 
COUNTER-ARGUMENT : "Even though there may be parts of your current-state workflow worth keeping, it's not to bring old habits into your new workflow - It's to make sure we're covering all of our bases, and doing the best job planning, designing, and executing that we can."
ARGUMENT : "It takes too much work to map the current state." 
COUNTER-ARGUMENT : "It doesn't need to take a lot of work, and you don't always need Visio swimlane diagrams. For many workflows, a simple well-written procedure with each line written as [WHO] will/may [WHAT] will do the trick. Even if it's not documented - it's still important that whoever plans the project has ample access to someone with a good understanding of the current-state workflow(s)."
Fortunately, most experienced Clinical #Informatics and #HealthIT professionals know the importance of mapping the current state in planning clinical improvement projects, and how to map it quickly. So if you ever need help mapping the current state, ask your local Clinical #Informatics or #HealthIT experts for assistance!

Remember, this blog is for academic discussions only - Your mileage may vary. Seek expert advice from your leadership, legal counsel, clinical informatics, or project management teams before changing strategies. Do you have any questions, comments, or feedback? Leave them in the comments section below!