Clinical Informatics and navigating Healthcare's 'Operating System' (OS)

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

For today's post, I thought I'd write about the intersection of Applied Clinical Informatics (CI) and what I call Healthcare's 'Operating System' (OS) - The daily documents, operations, governance, and decisions that together coordinate healthcare delivery.

To help better understand and navigate Healthcare's 'Operating System', I've broken it down into twelve (12) easy-to-digest mini-topics :

Let's get started : 

1. Healthcare Runs on More Than Software: What Clinical Informatics teaches us about Documents, Operations, Governance, and Clinical Workflow

After years of working in healthcare, medicine, information technology, and Clinical Informatics, I have gradually come to believe that many of healthcare’s hardest problems are not really technology problems - Many are really coordination problems.

And much of that coordination is hidden in something remarkably mundane: documents.

e.g., Policies. Procedures. Guidelines. Protocols. Bylaws. Regulations. Job descriptions. Committee charters. Project plans. Workflow diagrams. Order sets. Clinical decision support. Training materials.

We tend to think of these as separate things, each owned by different departments. After many years in Clinical Informatics, helping to support our users in delivering great patient care - I increasingly think they are all parts of the same system - the 'Operating System'. The challenge is getting that system to conduct.

2. Healthcare has a Document-Driven Operating System

Every healthcare organization has an enormous collection of documents describing what the organization believes should happen : 

• A regulation may establish an obligation.
• A policy may establish an institutional expectation.
• A procedure may describe how that expectation is carried out.
• A workflow may assign the work to particular people at particular moments.
• An EHR may operationalize portions of that workflow.
• Training teaches people how to perform it.
• Measurement tells us whether it actually happened.
• Governance determines who has the authority to decide what happens when these things disagree.

Seen this way, healthcare documents aren't simply paperwork - They are part of the organization's operating system.

And that raises a difficult question: What happens if the 'operating system' doesn't compile?

3. Aspirational vs. Operational Documents

Having spent years troubleshooting workflows, I've come to describe many healthcare policies as either 'aspirational' or 'operational'. 

An aspirational document might say, "Critical results will be communicated promptly to the appropriate provider." This sounds perfectly reasonable, and may even pass a regulatory review.

But try giving that same sentence to an EHR analyst, and asking them to build it. Immediately, questions appear : 

1. Q : Who exactly receives the result?
2. Q : What qualifies as critical?
3. Q : How quickly is "promptly"?
4. Q : Who initiates the communication?
5. Q : What communication methods are permitted?
6. Q : What happens if the first person doesn't respond?
7. Q : Who owns escalation?
8. Q : How is receipt acknowledged?
9. Q : Where is it documented?
10. Q : What happens overnight?
11. Q : What happens for an outpatient who has gone home?

Suddenly, the policy doesn't seem complete - it only appears complete.

An operational document goes further. It translates institutional intent into operationally executable instructions. As I've written about before, I generally reduce that concept to a deceptively simple structure:

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

The brackets matter - WHO and WHAT usually aren't optional. The other optional dimensions (modifiers) become explicit only whenever they are necessary for clarity, or to execute the work safely and consistently.

This is the basic foundation behind what I call Aspirational-to-Operational, or in short, #BlueprintsBeforeBuild :

Before asking technology to automate a workflow, make sure the organization has actually designed the workflow.

Software should not be asked to resolve ambiguities that organizational governance has not yet resolved.

4. The EHR Is Downstream of Governance

One of the most important lessons I've learned as a CMIO is that an EHR build request is often not really an EHR build request. For example, someone might ask : 

Q : "Can the EHR make us do this?"

Sometimes the answer is technically yes. But often, the more important questions are:

• Q : Who decided that we should do it?
• Q : Who owns the workflow?
• Q : Who has authority to change it?
• Q : Has everyone affected by it agreed to the change?
• Q : Is the policy consistent with the proposed build?
• Q : Who will maintain it after the implementation?

These aren't software questions - they are governance questions. And if governance has not yet resolved this ambiguity, it can flow downstream, where it first reaches Clinical Operations, then Clinical Informatics, and then Information Technology. 

Eventually - if someone asks an analyst to turn an unresolved organizational disagreement into an EHR button, this can be an extraordinarily expensive way to run a healthcare system.

5. Information Technology (IT), Clinical Informatics, Clinical Operations, and Project Management are Different Disciplines

Many healthcare organizations also blur these four functions that need to work together, but are not interchangeable : 

1. Information Technology (IT) manages the infrastructure. Servers. Networks. Devices. Applications. Interfaces. Identity. Security. Availability. IT makes the roads work.
2. Clinical Informatics (CI) manages information, knowledge, workflow, and decision support. It asks how information should move through those roads, what it means, when it should appear, and how it should support human decision-making. CI manages the traffic flows.
3. Clinical Staff and Clinical Operations (ClinOps) manage the actual delivery of care. It determines who is responsible for doing the work, with what resources, under what authority, and according to what operational expectations. ClinOps determines where everyone is trying to go — and why.
4. Healthcare Project Management (PM) coordinates how the organization moves from its current state to its intended future state by managing scope, sequence, timelines, dependencies, resources, risks, communication, milestones, and accountability. PM manages the journey.

So if :

• IT makes the roads work,
• CI manages the traffic flows, and
• ClinOps determines the destination — and why we're going there,

... then Project Management manages the journey.

Here's a helpful graphic, to help remember these four key roles : 

*Special thanks to : Eric Alper, MD (UMass Worcester), Bruce Darrow, MD (Mt. Sinai), Richelle deMayo, MD (CT Children’s), Katy L. Demitruk, MD MAS (Beacon Health), Roy Esaki, MD MS FASA (Queen’s Medical Center), Joel Gordon, MD (UW Health), Jeffrey Hoffman, MD (Nationwide Children’s), Allen Hsiao, MD FAAP FAMIA (Yale), Avniel Klein, MD PhD (Mt. Sinai), Yaa Kumah-Crystal, MD MPH FAMIA (Vanderbilt), Howard P. Levy, MD PhD (Maryland Primary Care), CT Lin, MD FACP FAMIA (Author and former CMIO, UCHealth), Mark Mabus, MD RPh (Parkview Health), C. Becket Mahnke, MD (MultiCare Health), Rebecca Mishuris, MD MPH FAMIA (Mass General Brigham), Brett Moran, MD (Parkland Health), Deepti Pandita, MD FACP FAMIA (UC Irvine), Heidi Twedt, MD FACP FAMIA (U of Wisconsin-Madison), Tara Cortez-Greig, MSN RN (Mass General Brigham/Cooley Dickinson Hospital), Michelle Currie MS RN CPHQ CPHIMS (CurAIte Health), Deborah Russo MSN RN NIBC (UConn Health), James J. McGennis, MPA PMP (Project Mgt Expert, UConn) … and many other Applied Clinical Informatics and Project Management leaders who contributed to developing this graphic.

*Key point : No role can replace the others. An EHR vendor cannot eliminate the need for Clinical Informatics any more than buying asphalt eliminates the need for traffic engineers.

And Clinical Informatics cannot substitute for Clinical Operations. The Clinical Informaticist (CI) can expose an unresolved workflow question, but the organization (ClinOps) still has to answer it.

6. Clinical Informatics Is a Translation Discipline

Over the past 17+ years, I've increasingly come to see Clinical Informatics as living at the boundaries between disciplines. While each group is technically speaking English, their motivations, cultures, and terminology are often very different : 

• Medicine speaks one way,
• Nursing speaks another,
• Operations another,
• Compliance another,
• Quality another,
• Finance another,
• Information Technology another,
• Software vendors another,
• ... and regulators sometimes seem to speak several languages simultaneously.

So very common words such as provider, clinician, protocol, guideline, standing order, referral, transfer, critical result, actionable finding, and even project can mean surprisingly different things, depending on who is speaking.

Clinical Informatics therefore isn't merely about configuring an EHR. A large part of the work is about translation : 

• We translate clinical intent into operational requirements.
• We translate operational requirements into workflows.
• We translate workflows into information requirements.
• We translate information requirements into technology.
• And then we translate what the technology can actually do back into language that clinicians and operational leaders can understand.

That translation layer is not overhead - It is part of the safety architecture.

7. Governance Is the 'Conduction System'

More recently, I've started thinking about healthcare organizations through another helpful metaphor: organizational 'electrophysiology'.

Huh? Stay with me : A healthcare organization resembles a heart more than we might realize.

• There are many capable cells.
• Many can generate activity independently.
• But truly effective performance requires coordinated conduction.

Similarly, healthy organizations have recognizable pathways through which authority, information, decisions, and work travel.

• Like a sinoatrial (SA) node, a Senior Leadership team provides the strategic impulses.
• Governance creates the conduction pathways.
• Clinical Operations produces the coordinated actions.
• Clinical Informatics helps translate and synchronize information across those pathways.
• Information Technology provides the infrastructure through which much of that information travels.

When those pathways work, thousands of people can act as a coordinated organization. When they don't, the organization begins behaving something like a heart with an arrhythmia :

• Committees fire independently,
• Departments create competing priorities,
• Projects originate everywhere,
• Policies contradict workflows,
• Technology teams receive conflicting instructions, and
• Executives become escalation pathways for routine operational decisions.

In this scenario, an organization may be extremely busy while accomplishing less than anticipated.

8. Organizational 'Ejection Fraction'

This led me to another analogy I've found useful: Organizational 'Ejection Fraction'.

Uncoordinated, a heart can consume enormous metabolic energy without producing effective forward flow. Analogously, healthcare organizations can do the same thing.

Imagine an organization putting 100 units of human effort into meetings, emails, projects, committees, escalations, presentations, and technology builds. Q : How much useful organizational work actually emerges?

A : If only 30 units become coordinated action, the organization has an 'organizational ejection fraction' of roughly 30%. The remaining energy hasn't disappeared - It has been consumed by friction : 

• Duplicate meetings.
• Competing priorities.
• Unclear authority.
• Policy ambiguity.
• Rework.
• Escalations.
• Failed handoffs.
• Poorly defined projects.
• Technology built before workflow was designed.

So the objective of good governance isn't to create more governance - it is to reduce organizational impedance. In short : Good governance should increase forward flow.

9. Why Organizations Become Surprisingly Efficient During Crises

After speaking with a number of Clinical Informatics colleagues over the years, several of them have described a very interesting phenomenon that sometimes happens in healthcare : 

Organizations that normally struggle to make a decision in six months can sometimes reorganize themselves in six hours during a crisis. 

Q : Why?

Because crises temporarily simplify governance : 

• Priorities become obvious.
• Authority becomes explicit.
• Competing initiatives disappear.
• Decision pathways shorten.
• One leader or command structure becomes the dominant pacemaker.

So for the cardiologists in my audience : In electrophysiologic terms, a crisis can behave almost like 'organizational adenosine' - the usual competing conduction pathways are interrupted long enough for a coherent rhythm to emerge.

*Note : The lesson shouldn't be that organizations need crises. Instead : 

• The lesson is that the organization was always capable of moving that efficiently, but...
• ... the crisis merely removed the routine organizational resistance that normally prevents it.

So the challenge for Healthcare leadership, in developing governance, is learning how to reproduce some of that clarity without requiring an emergency.

10. Documents, Governance, Operations, Informatics, and Technology Form a Chain

Based on these impressions, I've started thinking about healthcare delivery as a connected chain:

Regulation → Governance → Policy → Operations → Workflow → Informatics → Technology → Delivery → Measurement → Learning

Every arrow matters : 

• A failure upstream eventually becomes a problem downstream.
• Ambiguous regulation requires interpretation.
• Ambiguous governance produces conflicting policy.
• Ambiguous policy produces inconsistent operations.
• Inconsistent operations produce undefined workflows.
• Undefined workflows produce bad requirements.
• Bad requirements produce bad technology.
• And without adequate vigilance, bad technology can eventually reach a healthcare worker or a patient.

By the time the problem appears on someone's computer screen, the root cause may have occurred several organizational layers earlier. That is why endlessly "fixing the EHR" rarely fixes the underlying organization.

11. #BlueprintsBeforeBuild

Healthcare is generally good at buying technology - We are less consistent at designing the 'operating systems' into which that technology is placed. Before building something, we should be able to answer:

1. Q : Who owns this?
2. Q : Who has authority to implement this, on behalf of Clinical Leadership?
3. Q : Who routinely performs the work?
4. Q : What exactly are they expected to do?
5. Q : Under what circumstances?
6. Q : Using what information?
7. Q : What happens when the normal pathway fails?
8. Q : Where is the authoritative source describing this workflow?
9. Q : How will we know whether it worked?

Only then should we ask:

Q: What should the software do?

That is the essence of #BlueprintsBeforeBuild.

12. The Larger Lesson

Clinical Informatics is sometimes described as the intersection of people, process, and technology. While I very much agree with this, I do think this description may be a little incomplete. The field also sits at the intersection of:

authority, language, information, workflow, operations, technology, and human behavior.

The EHR is simply where many of those forces become visible : 

• When an EHR workflow is confusing, the problem may be software.
• But it may also be an unclear policy.
• Or undefined ownership.
• Or conflicting governance.
• Or inconsistent terminology.
• Or an operational process that nobody ever actually designed.

Clinical Informatics gives us a remarkable vantage point from which to see these failures because we live where organizational intentions collide with operational reality.

And perhaps that is one of the most important roles of the Clinical Informaticist:

• To make the invisible architecture of healthcare visible.
• To turn aspirations into specifications.
• To turn specifications into workflows.
• To make workflows understandable before they become software.
• To identify organizational 'arrhythmias' before they become patient-safety events.

And to help healthcare organizations convert more of their enormous human effort into coordinated forward flow.

Because ultimately, the end goal isn't : 

• better documentation, or
• better governance, or 
• better technology,

The goal is better delivery. Everything else is infrastructure.

----------------------------
For all of my talented Clinical Informatics colleagues out there, I hope this is a helpful summary that you can use for group discussion. Please feel free to adapt and share, or provide feedback below.

----------------------------
Remember, this blog is for education and discussion purposes only - Your mileage may vary.

Have any helpful Clinical Informatics insights you'd like to share? Have any experiences with workflows, governance, policies, or the 'Operating System' of Healthcare? Please feel free to share in the comments section below!

Where's the Clinical Informaticist?

Hello fellow CMIOs, CNIOs, and other Applied Clinical Informatics friends,

This month I'd share some cool discoveries I've made with some friends recently, in a helpful blog post about finding the Clinical Informaticist(s) in your organization, and/or identifying the need for them.

One of the common challenges of Applied Clinical Informatics is that Informaticists can sometimes be hard to find. Typically due to a number Human Resources (HR) and other industry issues, they can sometimes be hidden behind : 

• FALSE NEGATIVES - E.g. People who actually do Clinical Informatics work, but aren't necessarily titled "Clinical Informaticist" in their job title, or aren't recognized as doing Clinical Informatics work at all.
• FALSE POSITIVES - E.g. People who are called "Clinical Informaticist", when they don't necessary do the work that might commonly fall under the domain of the Clinical Informaticist (or they only do a specialty branch on the larger 'tree' of Applied Clinical Informatics - See below.)

While some have tried to tackle these HR challenges, concrete job descriptions are hard to find since there is such a wide variation of practice, in the general 'tree of Informatics' - which spans a number of disciplines related to both data storage ('data in') and data retrieval ('data out') functions : 

If your search for a Clinical Informaticist turns up negative, you will probably need to establish the need to hire one (or more) to help with your clinical workflow analysis and development. Historically, there have been two common approaches to doing this in #Healthcare - the 'Clinical Choir' approach, and the 'Executive/Financial' Approach: 

Each of these historic approaches come with some pros and cons : 

1. The 'Clinical Choir' Approach - Where the Clinical Staff recognizes the need for workflow updates and redesign, and collectively asks for Applied Clinical Informatics resources. PROS : Support from clinical end-users can be very helpful to support the allocation of FTE(s) for Clinical Informatics. CONS : Difficult to execute. Most clinical end-users aren't familiar with the potential role of Applied Clinical Informatics in their day-to-day workflows, so it's not easy to get them to ask for it by name. 
2. The Executive / Financial Approach - Where the Executive / Finance teams recognize the need for improved Return on Investment (ROI) and overall improved stewardship of technology investments, and so they collectively ask for Applied Clinical Informatics resources. PROS : Support from Executives and Finance officers can also be helpful to support the allocation of FTE(s) for Clinical informatics. CONS : Most ROI from workflow design and improvement falls under the category of 'soft ROI' which could easily be attributed to other departments, or it falls into the category of cost reduction rather than revenue improvements. (Both will help your organization, but one is easier-to-identify.) So putting a hard number to ROI or cost reduction that stands up to scrutiny will require some real pre-planning before you execute your improvement projects.

So for today, I'd like to share a new approach that I recently discovered, when I worked with some of my trusted Project management and Compliance colleagues (Jim McGennis and Elle Box) to combine my 10-step change management recipe with a Responsibility Assignment (RACI) Matrix :

First, a brief reminder that my recommended ten steps for clinical change management (originally published back in 2018) helps to create consistent outcomes through the thoughtful analysis, scoping, development, and planning of workflow changes (both big and small) :

After combining these ten change steps (above) with a Responsibility Assignment (RACI) Matrix (typically used by experienced Project Managers for assigning responsibility for various tasks), new discoveries were made and additional clarity was achieved. (Note : If you're new to Responsibility Assignment / RACI matrices, please see this Wikipedia article for a helpful introduction. And special thanks to PM guru Jim McGennis, for introducing me to this powerful tool.)

The basic premise of a RACI matrix is that you create a grid (spreadsheet) of roles versus steps, and then assign these four categories in each step : 

• (R)ESPONSIBLE (also recommender) - The one (or more) person(s) who are responsible to complete the task.
• (A)CCOUNTABLE (also approver or final approving authority) - Who is ultimately answerable for the correct and thorough completion of the deliverable or task, who also ensures the prerequisites of the task are met, and delegates the work to those responsible.
• (C)ONSULTED (sometimes consultant or counsel) - Those whose opinions are sought, typically subject matter experts (SMEs), and with whom there is two-way communication
• (I)NFORMED (sometimes informee) - Those who are kept up-to-date on progress, often only on completion of the task or deliverable, and with whom there is just one-way communication.

Putting my 2018 clinical change management recipe together with the RACI matrix has been remarkably helpful and enlightening. And with some help from Compliance colleages (thanks to Compliance guru Elle Box for her help reviewing and refining the descriptions), the first thing I began to notice was the number of roles that participate in one or more steps of change management : 

Roles that participate in one or more steps of clinical change management

 

Roles that participate in one or more steps of clinical change management

... as well as the details of exactly who is (R)esponsible, (A)ccountable, (C)onsulted, and (I)nformed at each step. (*Note : In the slide above, you'll notice that the Applied Clinical Informaticist already has a different set of roles and responsibilities than the Clinical IT Analysts. More to come on this shortly...)

When we look at the first phase of the change recipe (documentation of request and expectations, or intake) it's easy to see who has primary and secondary (R)esponsibility - Both the clinical end-user and the official requestor - their supervisor, director, chair, or chief - who needs to help support the request : 

First phase of change : Documentation of Request and Expectations ('Intake')

First phase of change : Documentation of Request and Expectations ('Intake')

As we move to the second phase of the change management recipe (Analysis, scoping, prioritization, resource allocation, and project approval), we can see that suddenly the Chief Information Officer picks up (A)ccountability, while the Applied Clinical Informaticist has primary (R)esponsibility for the literature search, sponsor identification, workflow gap analysis, workflow development, scoping of deliverables, and identification of stakeholders. Together with a number of (C)onsultants including Clinical IT Analysts, Medical Librarians, Compliance, Regulatory, and Finance, they will also help review regulations and estimate a Total Cost of Ownership (TCO) and Return-on-Investment (ROI), providing much more helpful information for Senior Executives who will need to prioritize and approve this project before it can be assigned. (*Note : By serving this important workflow analysis role, the Applied Clinical Informaticist will also become a subject matter expert (SME) for other experts who will be (R)esponsible for later steps in the change recipe.)

Second phase of change : Analysis, scoping, prioritization, resource allocation, and project approval

Second phase of change : Analysis, scoping, prioritization, resource allocation, and project approval

When we arrive in the third (Project Planning) phase, now the Executive Sponsor has picked up (A)ccountability, while the Project Manager has primary (R)esponsibility for working with the Applied Clinical Informaticist, Clinical IT Analyst, and others to plan the necessary parts of the project, including Gantt charts, RACI Matrices, and/or other formal project plans :

Third phase of change : Project Planning and RACI Matrix / Gantt Chart Development

 

Third phase of change : Project Planning and RACI Matrix / Gantt Chart Development

Assuming all of the above phases have been completed, this now brings us to the fourth phase of change - The drafting of workflows, for which the Applied Clinical Informaticist has primary (R)esponsibility, typically in conjunction with the Clinical IT Analyst, Compliance, and the End-users. 

Fourth phase of change : Drafting of Workflows

Fourth phase of change : Drafting of Workflows

While some organizations may not yet have implemented blueprints in their development process, this step can be very helpful because :

• Blueprints help to create understanding, align clinical stakeholders, let you conduct tabletop workflow discussions and reviews, and obtain preliminary approvals before the Clinical IT Analysts begin their build (in the next step).
• Once approved, and with a few small changes, blueprints can also become your downtime forms, in case your electronic system is ever down for planned maintenance or other unplanned reasons.

This now brings us to the fifth and sixth phases of change, the building of deliverables and testing of workflows, where the Clinical IT Analyst now has primary (R)esponsibility to build and test the deliverables, typically in conjunction with the Applied Clinical Informaticist and the End User (for end-user acceptance testing).

Fifth and sixth phases of change : Building of deliverables and testing of workflows

 

Fifth and sixth phases of change : Building of deliverables and testing of workflows

For the seventh phase of change (Final workflow approval), the Applied Clinical Informaticist now assumes primary (R)esponsibility and works to secure the necessary final approvals in conjunction with Senior Leadership and a number of other stakeholders. (*Note that the Executive Sponsor still has (A)ccountability for this step.)

Seventh phase of change : Final Workflow Approvals

 

Seventh phase of change : Final Workflow Approvals

 

Finally, for the eighth phase (Communication and Education/Training), ninth phase (Implementation/Publication), and tenth phase (monitoring and support) of change, the Clinical IT trainers, Clinical Education / Training team, Communications Team, and End-Users now all share (R)esponsibility, and typically do their steps in conjunction with the Applied Clinical Informaticist and the Clinical IT Analysts.

Eighth, ninth, and tenth phases of change : Communication, Education, Implementation, Monitoring, and Support

 

Eighth, ninth, and tenth phases of change : Communication, Education, Implementation, Monitoring, and Support

IN CONCLUSION : 

What does this exercise (combining change management recipe with a RACI responsibility assignment matrix) teach us? Five helpful take-home points : 

1. Clinical change management is a team sport that requires the participation of a large number of stakeholders to work together in a clear, highly-detailed, highly-coordinated fashion, where different roles will be (A)ccountable for some steps, have primary (R)esponsibility in some steps, serve as a (C)onsultant in other steps, and need to be (I)nformed of other steps.
2. The roles of the Applied Clinical Informaticist and Clinical IT Analyst are separate and distinct roles that often work together, but serve in distinct and unique capacities, and thus should have separate and distinct job titles and descriptions.
3. Before projects are approved, the Applied Clinical Informaticist has primary (R)esponsibility for the analysis, scoping, prioritization, and resource allocation, typically in conjunction with (C)onsulting expertise from the Clinical IT Analyst, End-users, Compliance, Regulatory, Finance, Executive Sponsor(s), and Senior Leadership.
4. The Applied Clinical Informaticist also has primary (R)esponsibility for the drafting of workflows (blueprints of deliverables), typically in conjunction with (C)onsulting expertise from the Clinical IT Analysts, Compliance, and End-Users. These blueprints will help to create understanding and alignment, and later serve as downtime forms in the event of a planned or unplanned downtime. 
5. The Clinical IT Analyst often provides (C)onsulting expertise during earlier analysis and scoping phases of the change, but then assumes primary (R)esponsibility for the building and testing of electronic deliverables, before providing additional (C)onsulting expertise during the implementation phase of the change. 

I know there's a lot to unpack here, but I hope this review helps to demystify the process, and helps you look at your own change recipe and the roles that are (A)ccountable for,  (R)esponsible for, (C)onsulting on, and (I)nformed of each step. I also hope it helps to dispel the misunderstandings and confusion about the roles of the Applied Clinical Informaticist and the Clinical IT Analyst, two important roles that often work together but each of which require their own skill sets, job titles, job descriptions, and support.

Remember, the above is all a [ DRAFT ] and this blog is for educational and discussion purposes only - Your mileage may vary! Have any feedback or experiences you would like to share? Please feel free to leave comments in the comment section below!

Definitions, Templates, Documents, and Workflow Design - the Video!

Hi fellow CMIOs, CNIOs, and other Informatics friends,

I'm writing today to share a video adaptation of a lecture I did last year for a Physicians in AMIA meeting (thanks to Dr. Richard Schreiber!), where I shared a bunch of the lessons I've learned during my 16-year career as an Applied Clinical Informaticist and CMIO. 

If you're interested in Applied Clinical Informatics or workflow design, I think you'll like this video. My adapted version is about 26 minutes long, but it contains as much information and background as I could fit. And with a standard YouTube format, you can now pause and resume on any slide!

(Click above icon to open)

So if Applied Clinical Informatics, workflow design, or reducing clicks and burnout are your thing, I hope this video helps you. Please feel free to leave questions or feedback in the comments section below!

And for those of you who prefer printed slides, instead of video - I'm also working on a printed version of this presentation shortly!

Have any helpful experiences in developing clinical workflows? Or just want to share any lessons learned? Feel free to leave feedback in the comments section below!

Optimizing Lumbar Punctures, Part I

Hi fellow Clinical Informaticists, CMIOs, CNIOs, #workflow gurus, and other #HealthIT friends,

How do you say 'Lumbar Puncture' in CPOE? Today, I'm writing to share the translation of one of the oldest, most common medical procedures that's routinely done in modern healthcare : The lumbar puncture, sometimes referred to as an 'LP'.

Lumbar punctures (LPs) are routinely performed to help look for infections, look for malignancy, and look for antibodies and other markers of neurologic disease. While they are a common mainstay of modern healthcare, building them electronically can be quite a challenge. 

Want to reduce clicks when ordering your LPs? It helps to first have a solid understanding of the most common LP workflows in healthcare, so you can build your order sets with the most common studies, priorities, indications, and order statuses all properly built and correctly defaulted.

So in this post, I figured I'd share some secrets about the four most common lumbar puncture workflows, and how to build them into an EMR, in a really gourmet fashion - for the best diagnostic yield, fewest clicks, and maximal success. 

1. THE WORKFLOWS

Lumbar punctures are commonly done for diagnostic purposes, but can also sometimes be done for therapeutic purposes. But as it turns out, the LP is not just one workflow - It's actually four different workflows : 

In each of these scenarios, there are different clinical specialties using the LP, commonly for different purposes : 

In addition to these workflow descriptions, some helpful notes : 

• In workflows #2 and #3 above, there is a often a communication challenge between the ordering provider and the Interventional Radiologist, who has to collect, label, and transport the samples to the lab, and also report back some findings to the ordering provider (e.g. opening pressures, turbidity, etc.)
• In workflow #3 above, there is also sometimes a patient education challenge, whereby the patient needs to come before the scheduled IR LP to have 'pre-procedure' labs drawn (e.g. CBC, BMP, PT/INR) to help ensure that the LP can proceed without problems. 

2. THE STAKEHOLDERS

Given the above workflows, the physician specialties most commonly involved with lumbar punctures then include :

1. Emergency Medicine
2. Inpatient Physicians - Pulmonary/Critical Care (Intensivists)
3. Inpatient Physicians - General Inpatient Medicine (Hospitalists)
4. Interventional Radiologists (IR)
5. Ambulatory/Inpatient Specialists - Infectious Disease Physicians
6. Ambulatory/Inpatient Specialists - Neurologists - General
7. Ambulatory/Inpatient Specialists - Neurologists - Movement Disorders
8. Ambulatory/Inpatient Specialists - Neurologists - Multiple Sclerosis
9. Ambulatory/Inpatient Specialists - Neuro-ophthalmologists
10. Ambulatory/Inpatient Specialists - Hematology/Oncologists

If we include :

• the Registered Nurses (who have to help care for the patient before/after lumbar punctures), 
• the pharmacists (who help provide the medications the provider has ordered for sedation/anesthesia)
• the laboratory workers (who receive the fluid, provide the on-site analysis of certain labs, and send out other labs to external labs) 
• the IT/Informatics workers (who connect with stakeholders, map the current state, and work with the clinical stakeholders to design, build, and test the future state)

... then this gives us a fairly long list of stakeholders in the most common lumbar puncture workflow discussions : 

1. Emergency Medicine Providers
2. Inpatient Physicians - Pulmonary/Critical Care (Intensivists)
3. Inpatient Physicians - General Inpatient Medicine (Hospitalists)
4. Interventional Radiologists (IR)
5. Ambulatory/Inpatient Specialists - Infectious Disease Physicians
6. Ambulatory/Inpatient Specialists - Neurologists - General
7. Ambulatory/Inpatient Specialists - Neurologists - Movement Disorders
8. Ambulatory/Inpatient Specialists - Neurologists - Multiple Sclerosis
9. Ambulatory/Inpatient Specialists - Neuro-ophthalmologists
10. Ambulatory/Inpatient Specialists - Hematology/Oncologists
11. Nursing - Interventional Radiology
12. Nursing - Floor/Bedside
13. Nursing - Clinics
14. Laboratory
15. Pharmacy
16. Clinical IT/Informatics

... and you'll quickly see why you it's helpful to have a good clinical informatics and project management team available, to help coordinate all of the meetings, discussion, architecture, building, testing, and approvals before you can go-live. In short : Optimizing LP order sets is usually a significant project effort, requiring many meetings.

3. THE LABS

With regard to the actual laboratories, it's helpful to keep in mind that workflows #1 and #2 are general-purpose LPs, usually for the emergent ruling out of CNS infection. It typically doesn't get much more complicated than that. So for Inpatient/ED purposes, the most common studies include : 

• CSF Cell Count and Differential
• CSF Gram Stain and Culture
• CSF Protein
• CSF Glucose
• (Occasionally CSF HSV PCR, if clinically indicated)

But for workflows #3 and #4, they are more specialty-oriented, so their labs may include the general labs above, but also include a number of complex, high-cost specialty panels, antibodies, proteins, and pathology / flow cytometry. 

Commonly, the occasional ordering of these specialty studies (commonly from workflows #3 and #4 above) in the Inpatient/ED settings (commonly workflows #1 and #2 above) can generate a lot of discussion. For reimbursement reasons, it's helpful to stratify these workflows, but keep in mind - In complex cases, there may still be reasons to order the more complex outpatient labs on an inpatient, but generally they should only happen with specialist review and approval.

4. THE ORDER SETS

So now you're faced with the question - One order set, or four order sets?

If you do one order set, you'll probably end up needing to stratify them (with radio buttons!) into the four different workflows, e.g. : 

Or, more likely for operational, culture, and other EMR configuration reasons, you may end up with four different order sets - In which case you will want to choose your naming convention very carefully, e.g. : 

1. LUMBAR PUNCTURE (LP) - INPATIENT/ED - AT BEDSIDE
2. LUMBAR PUNCTURE (LP) - INPATIENT/ED - IN IR
3. LUMBAR PUNCTURE (LP) - AMBULATORY/OUTPATIENT - IN IR
4. LUMBAR PUNCTURE (LP) - AMBULATORY/OUTPATIENT - IN CLINIC

Even though #1 and #2 above are typically used by generalists, and #3 and #4 above are typically used by specialists - You'll still want to have specialty input into #1 and #2, to help make sure that the common specialty scenarios can still be addressed (when they arise) in the inpatient settings. (E.g. Having Infectious Disease provide input into #1 and #2 can help make sure your ED providers/Hospitalists/Intensivists are ordering the right ID labs for the right scenarios.)

In my next post, we will look at these four LP workflows in more detail, and discuss some of the common educational, operational, and ordering challenges that organizations may come across when building out and optimizing these order sets. 

Have any thoughts, comments, feedback, or stories to share about building highly-optimized (gourmet!) lumbar puncture workflows? Feel free to leave in the comments section below!

Remember, this blog is for educational / discussion purposes only, and does not constitute medical advice - Your mileage may vary. Always consult your clinical leadership, your clinical informatics team, and your medical specialists before building out any order sets in your own organization.