How I Became a 'Document Whisperer'

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

I'm writing today to share some stories from my career path in Applied Clinical Informatics, and how I became a 'document whisperer' with regard to clinical workflow design. This post stems from a common question I get asked: 

'If you care so much about clinical workflows - Then why do you seem to care so much about bylaws, policies, procedures, guidelines, protocols, bylaws, charters, order sets, and other documents? Why don't you just worry about the things inside the EMR?' 

The reason is because all of these documents (whether they are inside or outside an EMR) work together to shape clinical workflow. 

To explain, I need to first offer some context. 

Back in 2007 when I first started my formal clinical informatics career, like most newcomers, I didn't yet have enough experience to fully understand my role. I figured my job was to 'help with the electronic medical record', so naturally, I focused mainly on the things that doctors interacted with inside the EMR. 

After a while, however, I started to see challenges we had with some of our projects. There were order sets that, after we built them, didn't get used. There were order sets that created turbulence with other workflows when we rolled them out. I received complaints from doctors who felt the computer was 'too clunky' and that 'it takes too long to get things done'. 

Initially, I wondered if this was simply a matter of an EMR just being more difficult to use. There were some people who told me, 'Oh, some doctors are just resistant to change' (which is partly true), and others who told me, 'Computers are just complicated and finicky' (which can also sometimes be true).

But I kept looking for a better answer - There must be some sort of symmetry here that I was missing. 

And then, over the next 2-3 years, I experienced two important things : 

1. I once worked on a complex titration protocol, which required an extensive analysis to fully build out the protocol, and...
2. One day, a Registered Nurse complained to me about a policy that would need to be updated, in conjunction with a project we were actively working on.

So it was while confronting the question of 'How exactly do you write a protocol?' that I started to really confront the question : "What exactly is a protocol?" This led to even more questions, like : 

Trying to find more concrete answers, I looked to various potential sources, including various regulations, the International Standards Organization (ISO), the National Institute of Standards and Technology (NIST), the CMS web site, various HealthIT/Informatics societies, ITIL, and even Black's Law Dictionary, without much help. 

So around 2010, I decided to look at this from a more analytical, design-thinking standpoint : 

"If we gathered every document in healthcare, both those sitting on desks and on hard-drives - what would they be, and what would they look like?"

This led me to scribbling down some commonly-used words people use in healthcare, putting them into a spreadsheet, and in 2010 I came up with my first CMIO's Checklist : 

[ FIRST DRAFT ] Note : My workflow definitions have evolved since this 2010 version.

[ FIRST DRAFT ] Note : My workflow definitions have evolved since this 2010 version.

... which turned out to be my first real foray into clearly-defined terms, tools, and functions. Yes, a sample size of one - based only on my own clinical and administrative experiences - but a fairly comprehensive function-based analysis, nonetheless, that helps to clarify concepts and increase shared understanding.

(What good, functional, policy-grade definitions do to clarify concepts

and increase shared understanding - Hit PLAY to see animation)

Now with this new function-based analysis in hand, I stumbled into two interesting [DRAFT] functional definitions : 

Template (n.) - A tool used to standardize and expedite the creation of a document. 

... and ...

Document (n.) - A tool used to record and transmit information.

... both of which shed light on an important concept - For many of you, this may be common-sense or trivial, but for me it was a 'eureka' moment : 

• Definitions can be used to create templates.
• Templates can be used to create documents.
• Documents can be used to store and transmit the information needed to support workflows.

So around 2015, this led me to the realization that these concepts all depend on each other. And so, realizing that workflow inconsistencies sometimes arise from misalignment of these concepts, I wrote this blog post about workflow management and the Clinical Informatics domain : 

[ SCREENSHOT ] From Informatics Domain and Workflow Management, 2015

 

This also led me to the realization that all of the documents and tools contained in drawer #4 above :

• needed to be aligned with the workflows, goals, and mission above it, and... 
• were shaped by the concepts contained in #5, #6, #7, and #8 below it. 

It also revealed to me that some of the documents and tools that support workflows are typically contained inside the EMR, and others were contained outside the EMR : 

So now being able to mentally visualize this conceptual structure (above), I also realized that : 

• Workflow depends on all of these tools (above) for support. 
• Changing workflow means changing all of the tools (both inside and outside the EMR) that are used to support the workflow.

... and so effective workflow change management means : 

1. Clearly understanding each deliverable (tool) above.
2. Identifying the deliverables (both inside and outside the EMR) that are needed (or need to change) to support the desired workflow. 
3. Quickly drafting those deliverables, to demonstrate to users and HealthIT professionals how the deliverables need to fit together,
4. Reviewing those draft deliverables with clinical stakeholders, to confirm their needs/expectations before committing them to a formal build, and to help get their input and align expectations.

So to help quickly draft the deliverables in step #3 above, I had to quickly make templates for these roughly 24 documents that we commonly use in healthcare. And this brought me back to my pursuit for high-quality, high-grade definitions so that my workflow templates were quick, easy-to-use, and maybe most important - functionally sound. 

And this is essentially how I became a document whisperer for good clinical workflow design and EMR support. Using this deeper understanding of how these common concepts are related has helped me to quickly draft the 'workflow blueprints' that help to outline workflows, identify deliverables, identify stakeholders, create clarity, develop understanding, and align expectations before beginning a project. (This understanding has proven especially useful when scoping/analyzing clinical project requests prior to approval.)

 

I hope sharing this journey helps give you a roadmap for your own journey, and helps you develop your own definitions, templates, and tools for rapid workflow analysis and scoping before undertaking any significant projects. 

Remember this blog is for educational purposes only - Your mileage may vary. Have any anecdotes or stories to share about workflow analysis or development? Feel free to leave them in the comments section below!

An Opinion : What exactly are "Protocols" and "Standing Orders"?

[ File under : FOR EDUCATIONAL DISCUSSION ONLY ] 

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

Protocols and standing orders. Next to order sets, these are two of the most ubiquitous tools in modern healthcare, used to create predictable routines and outcomes in clinical care. So what exactly are they? And what exactly is the difference between a "protocol" and a "standing order"?

For the Informaticist, these are not easy questions to answer. The confusion starts with the search for regulations and definitions, where there is a curious paucity of information. As of this writing, most major regulatory bodies have somewhat vague or conflicting information. 

Historically, it seems many regulatory bodies simply frowned upon the use of "protocols" or "standing orders". Why? Probably because of their function - If a doctor writes an order like "Vent liberation per protocol", he/she is actually asking someone else to take on the responsibility of managing a ventilator on his/her behalf. So it's actually a tool of delegation.

So I'm guessing the concern was, if the 'protocol' was a tool of delegation, then it's someone else providing that care at the direction of, and on behalf of the doctor. This raises some valid operational questions : 

1. By using "per protocol", does the order actually refer to a approved, documented set of well-defined, clear, reasonable, evidence-based, and agreed-upon instructions?
2. If a nurse, pharmacist, or someone else can follow those instructions - What if something doesn't go according to plan? Would the nurse, pharmacist, or other care team member have the same skills and training as the doctor to manage any unexpected outcomes or scenarios?
3. As the nurse, pharmacist, or other ancillary team member follows the written instructions - Are there any key points in the patient's care that the ordering doctor should at least be aware of? (e.g. if the protocol keeps asking the nurse to give  higher levels of oxygen, is that OK?)
4. If the doctor is effectively unaware of the minute-by-minute details of what the nurse or pharmacist is doing, or the patient status, will the doctor still be responsible for the outcome of their pre-defined instructions? Or will the nurse or pharmacist be responsible?
5. How do we know this delegation agreement was clear, effective, and appropriate?

So for many years, many of those regulatory agencies were concerned and understandably frowned upon the use of protocols and standing orders. Not enough was known about them, and the risks seemed to outweigh the benefits. And let's face it - If it's a tool of delegation, what's to stop a doctor from writing the "Dr. ______-is-away-this-weekend-protocol", making the nurses shoulder all of the responsibility for care? 

But then, around 2008, after more rigorous discussion and a few safety incidents where nurses were unable to initiate common life-saving treatments because their patients needed them and no doctor was immediately available - it seems like some agencies may have re-looked at protocols and standing orders, had a change of heart. In 2011, CMS issued this communication : 

https://www.cms.gov/Regulations-and-Guidance/Guidance/Transmittals/downloads/R77SOMA.pdf 

... which says : 

"Standing orders 

Hospitals may adopt policies and procedures that permit the use of standing orders to address well- defined clinical scenarios involving medication administration. The policies and procedures must address the process by which a standing order is developed; approved; monitored; initiated by authorized staff; and subsequently authenticated by physicians or practitioners responsible for the care of the patient. The specific criteria for a nurse or other authorized personnel to initiate the execution of a particular standing order must be clearly identified in the protocol for the order, i.e., the specific clinical situations, patient conditions or diagnoses in which initiating the order would be appropriate. Policies and procedures must address the education of the medical, nursing, and other applicable professional staff on the conditions and criteria for using standing orders and the individual staff responsibilities associated with their initiation and execution. An order that has been initiated for a specific patient must be added to the patient’s medical record at the time of initiation, or as soon as possible thereafter. Likewise, standing order policies and procedures must specify the process whereby the physician or other practitioner responsible for the care of the patient acknowledges and authenticates the initiation of all standing orders after the fact, with the exception of influenza and pneumococcal polysaccharide vaccines, which do not require such authentication in accordance with §482.23(c)(2). 

The policies and procedures must also establish a process for monitoring and evaluating the use of standing orders, including proper adherence to the order’s protocol. There must also be a process for the identification and timely completion of any requisite updates, corrections, modifications, or revisions." 

This was a big step forward in creating some clarity around the subject of "standing orders", but does this also apply to "protocols"? It seems there is still a great deal of confusion over this issue. Articles like these : https://www.medscape.com/viewarticle/775617  suggest that people are still trying to understand if these are legal, and if so, how to design them safely.

So from a terminology standpoint, most Informaticists routinely have to struggle with questions like : 

1. "What exactly is a protocol?" and 
2. "Is it the same as a standing order?" or 
3. "Is it the same as a clinical protocol?" and 
4. "Is it the same as an oncology protocol?"

These are not easy questions to answer when the regulations and definitions don't guide you very well. 

So what is an Informaticist to do to help resolve the issue? Focus on the function, and work backwards to redefine the archetype and definition!

Let's look at a few things we *do* know : 

1. The terms "Protocol" and "Standing Order" are almost used interchangeably - But not quite - So they still must have some kind of relationship.
2. They seem to allow someone else than the provider to enter, modify, or stop an order, on behalf of the provider - so they appear to be some kind of tool of delegation.
3. They seem to follow some kind of documented instructions, explaining exactly WHICH order(s) to start, modify, or stop, and when.
4. For safety, the reasons that someone else is starting, modifying, or stopping an order should be very concrete and clear, without need for interpretation.

So if we can accept the above as true, then we can start drafting a definition :

[ DRAFT ] DEFINITION - PROTOCOL (n.) - A tool of delegation that allows a __________ to INITIATE, MODIFY, or DISCONTINUE an order on behalf of a Licensed Independent Practitioner (LIP), Advanced Practice Registered Nurse (APRN) or Nurse Practitioner (NP), Resident Physician, or Physician Assistant (PA).

Now, who exactly can start/modify/stop an order on behalf of a provider? From the patient care standpoint, you want the person following the protocol to have the training and clinical understanding to follow the protocol properly, and know how to navigate when things don't go as planned. Commonly, there are four roles that could likely fill this role : 

1. Registered Nurses
2. Registered Pharmacists
3. Registered Dietitians
4. Registered Respiratory Therapists

But if you want to include other care team members (like Medical Assistants), it is probably in an organization's best interest to make sure all team members expected to follow the protocol have a solid system of certification, training, and supervision. Either way, you'll need to work this into your organization's definition of a protocol : 

[ DRAFT ] DEFINITION - PROTOCOL (n.) - A tool of delegation that allows a Registered Nurse, Registered Dietitian, Registered Pharmacist, Registered Respiratory Therapist, (or certified and trained Medical Assistant) to INITIATE, MODIFY, or DISCONTINUE an order on behalf of a Licensed Independent Practitioner (LIP), Advanced Practice Registered Nurse (APRN) or Nurse Practitioner (NP), Resident Physician, or Physician Assistant (PA).

This is a pretty good start, but let's see if we can help craft some additional functionality and safety into this definition. 

If protocols should address common, well-understood clinical scenarios, then we need to consider what types of common, well-understood scenarios we might need protocols for : 

1. Scenarios that only apply to a specific patient (e.g. Heparin titration protocols, Vent Liberation Protocols), and
2. Scenarios that apply to a population of patients (e.g. Nurse vaccination protocols, pharmacy substitution protocols, etc.)

And so it seems like there is a need for two different kinds of protocols : 

1. Protocols that only apply to a specific patient (e.g. Heparin titration protocols, Vent Liberation Protocols), and
2. Protocols that apply to a population of patients (e.g. Nurse vaccination protocols, pharmacy substitution protocols)

And so, this suggests that the term "Protocol" might actually comes in two types : 

[ DRAFT ] DEFINITION - PROTOCOL (n.) - A documented tool of delegation that allows a Registered Nurse, Registered Pharmacist, Registered Dietitian, Registered Respiratory Therapist, (or certified and trained Medical Assistant) to INITIATE, MODIFY, or DISCONTINUE an order on behalf of a Licensed Independent Practitioner (LIP), Advanced Practice Registered Nurse (APRN) or Nurse Practitioner (NP), Resident Physician, or Physician Assistant (PA). All protocols are categorized as either : A. Protocols that apply only to a specific patient, or B. Protocols that apply to a defined population of patients. 

So if a protocol only applies to a specific patient, there must be some way that a provider can specify which patient(s) to use the protocol on - A way of turning the protocol "on-and-off", to tell a nurse when to follow the protocol, and when NOT to follow the protocol.

Likewise, for those protocols that apply to a defined population of patients, there must be some way to define which population of patients the protocol should be applied to.

And this brings us to the question of how to initiate/activate, or 'trigger' a protocol - If you need to activate/deactivate the protocol, then a handy trigger would be an ORDER, e.g. :

• "Initiate/Follow heparin titration protocol" and 
• "Discontinue/stop heparin titration protocol".

But if it's a protocol that is 'always on' for a defined group of patients (say, adult inpatients), then a handy 'trigger' could be a POLICY, e.g. "All adult inpatients will be on the pharmacy PPI substitution protocol" that allows a pharmacist to STOP one PPI and START another PPI (to replace one for the other).

So if we can accept that there are probably two ways to activate/'trigger' a protocol : 

1. ORDERS - For those 'on-off'-type protocols, that need to be initiated/discontinued for a particular patient
2. POLICY - For those 'always-on'-type protocols, that are always in effect for a defined patient population

... then we can work this into our drafted definition of a PROTOCOL (click below to enlarge): 

... and for additional clarity, we can bring in a few common, real-world examples below : 

So this is a reasonable starting point. But does this help us, yet, with a definition for "Standing Order"? I think it does - The term "Standing Order" is commonly used to describe scenarios where the provider has granted pre-approved, written, delegated authority to perform an action without their input or awareness. This is especially helpful in common scenarios where the risks/benefits of administration outweighs the risks/benefits of getting a provider order - E.g. For Public Health reasons, many states allow Registered Nurses to order and administer (low-risk) vaccinations without a provider's input.

So is it possible that the term "Standing Order" is actually a synonym for all or part of this protocol definition? I think it works pretty well for part 1.b below : 

And so, a "Standing Order" could then be defined, simply, as a PROTOCOL that is initiated/triggered by a POLICY (See section 1.b above.)

This leads me to ask about other common terms/synonyms - E.g. "Nurse-driven protocol", "Pharmacy-Driven Protocol", "Respiratory Therapy Protocol", etc. What exactly are these?

The problem with these other synonyms is that the terminology overlaps a bit, and when referring to a protocol, it's important to note both the method of initiation (e.g. Policy or Provider), and the team member(s) expected to follow the protocol, to initiate orders on behalf of the attending or ordering provider (e.g. Registered Nurse, Registered Dietitian, Registered Pharmacist, etc.)

So when referring to a protocol, it's always important to consider both : 

• "____________-INITIATED protocol" - Describes the mechanism for initiating/triggering the policy (e.g. Provider-initiated, Policy-initiated)
• "____________-DRIVEN protocol" - Describes the team member(s) who is/are expected to follow the protocol (to start/modify/stop orders, on behalf of a licensed prescriber) (e.g. Nurse-driven, Pharmacy-driven, Dietary-driven, etc.)

We can use these terminology concepts to help fill out our definition of a protocol / standing order even more - see 'synonym : Provider-initiated Protocol' in 1.a below :

And if we want to give some examples of each type of trigger, to help make the definition even more clear, we could include them too  - See 1.a.i and 1.b.i below : 

This is a pretty good start, but we'll want to work in some features of attribution, for the orders that are initiated, modified, or discontinued by these protocols. Since we now have a definition with two types of protocols : 

1. Order-Initiated (aka Provider-initiated protocols)
2. Policy-Initiated (aka Standing Orders)

It makes sense that for the resulting 'child' orders : 

1. Order-Initiated (aka Provider-initiated protocols) - Attributed to the ORDERING provider
2. Policy-Initiated (aka Standing Orders) - Attributed to the ATTENDING provider

And we can work this into our definition, too - See 1.a.ii and 1.b.ii below : 

Finally, for safety, we should consider the circumstances in which someone else other than a doctor might assume responsibility for INITIATING, MODIFYING, or DISCONTINUING an order - We want it to be very clear about WHEN, exactly, to start/modify/stop that order - In other words : 

1. ACCEPTABLE = Clear, discrete data elements
2. UNACCEPTABLE = Vague, ambiguous, or complex data elements

So we can work this safety feature into our definition too - See #2 below : 

This definition is much more robust than many regulatory agencies currently offer or publish. Some might see the adoption of such a definition as risky ("You don't want to paint yourself in a corner!") - However, it does provide a great deal of clarity and predictability, and if it exceeds the expectations of the regulatory agencies, then you are still meeting their expectations while simultaneously creating clarity and predictability - Which creates more predictable outcomes, which can lead to faster development time, higher development standards, and more standardized care. Before deciding whether or not to adopt such a definition and approach in your organization, your legal counsel, senior leadership, and informatics leadership will need to discuss the risks and benefits in detail.

However, if after rigorous examination and debate, you do adopt a similar definition, then it could help you answer questions like : 

• Q : "What exactly is a protocol?"
• A : See the [ DRAFT ] definition below (click to enlarge) : 
• Q : What exactly is a standing order?
• A : It is a PROTOCOL which is activated/triggered by a POLICY. The provider is not required to initiate action, and child orders are attributed to the ATTENDING provider. See the definition of PROTOCOL, section 1.b above.  
• Q : Do I always need to activate a PROTOCOL with an order?
• A : No - See the definition of PROTOCOL, section 1.b (aka 'Standing Order'). 
• Q : Is a PROTOCOL the same as a 'research protocol'?
• A : Without a solid definition of 'research protocol' it is not easy to answer this, but research protocols are typically used to guide the screening of research subjects, plan their data collection and management, with the goal of studying a subject. A PROTOCOL is only used to define a common clinical scenario where a licensed prescriber is delegating the authority to start, modify, or stop an order on his/her behalf.
• Q : Is a PROTOCOL the same as an 'EMS protocol' or 'Emergency Protocol'?
• A : Without a solid definition of 'EMS protocol' or 'Emergency Protocol', this is difficult to answer concretely - But in fact, many state EMS protocols have the same sort of functionality as a clinical PROTOCOL - Allowing a trained medical professional (paramedic or EMT) to initiate care in the field, on behalf of a supervising Emergency provider or Medical Director.

In my next blog post, I'll show how such a [ DRAFT ] definition could help you develop a protocol template that supports your protocol definition by creating an easy way for your protocol-builders to plan and build a professional-looking protocol document that supports your desired workflow and EMR configuration.

Remember this blog is for educational discussions only - You should consult your own legal counsel, senior leadership, and informatics professionals before considering adoption of any of the above approaches or definitions. Have any good definitions or regulations to share, or other ideas or comments? Leave them in the comments box below!

How to spot and fix a Frankenform

Hi readers - As I write this last post for 2015, I'm going to explore one of the most common questions that Informatics professionals get asked : "Why can't you just make this paper form electronic?" - 

The most common answer that Informatics professionals respond with is, "Well, you just can't", usually followed by some sort of an awkward smile and an answer that sounds like, "You know those computers, they are always so difficult." 

But there is a real reason, with a better answer. To help explain that answer, I'd like to introduce a new concept - The Frankenform.

A. FIRST, SOME COMMON DEFINITIONS

Before we go on, I just wanted to review some DRAFTED definitions of a few common archetypes we all use in healthcare. They include : 

1. POLICIES - Tools used to describe an organizational standard
2. PROCEDURES - Tools used to describe a series of actions conducted in a certain order or manner
3. GUIDELINES - Tools used to educate staff about how to achieve a desired outcome
4. ORDERS - Tools used to document an instruction to deliver a defined type of care to a defined patient at a defined date/time in a defined manner (sometimes for a defined reason)
5. ORDER SETS - A collection of ORDERS used to standardize and expedite the ordering process for a common clinical scenario
6. CLINICAL PATHWAYS - A collection of ORDER SETS used to standardize the care for a common clinical diagnosis
7. PROTOCOLS - Tools that allow a nurse, pharmacist, or other licensed medical professional to start/modify/stop a patient care order on behalf of a licensed physician.
8. DOCUMENTATION - Tools used to record and transmit information
9. STAFF/PATIENT EDUCATION - Tools used to educate staff/patients about a particular topic
10. STAFF SCHEDULES - Tools used to determine who is responsible at a particular date/time
11. BUDGETS - Tools used to allocate resources for a project or initiative

These definitions will be helpful in spotting Frankenforms - Forms that often combine these functions.

B. THE FRANKENFORM

So what exactly is a "Frankenform"? It's a term that Informaticists sometimes use, loosely, to describe paper forms that combine more than one of the above functions, or are used by different people in different scenarios. If I had to write a better definition, it might be described as : 

Frankenform (n.) - a form or document that is designed with more than one archetype, role, or scenario in mind.

Frankenforms existed all over in the paper world. While they are often convenient (having everything in one place), they generally don't behave well in the electronic world because : 

1. They contain documentation recorded from two different roles. (e.g. the dietitian and physician both signing off on one TPN order)
2. They contain two different archetypes (e.g. part-policy-part-order-set, or part-policy-part-guideline, or part-documentation-part-order-set, etc.
3. They contain documentation from two different scenarios. (e.g. the sometimes-seen, all-encompassing "antibiotic order set" which contains antibiotics to cover all scenarios, from pre-op antibiotics to treatment of sepsis) - These all-encompassing tools are sometimes also called "pick lists", because they can be used in almost any scenario.)

Electronic medical records generally will not allow you to build Frankenforms into their systems because of these three reasons :

1. They enforce legal-grade authentication - So a form used by two different people must be re-engineered to find out who-is-filling-out-what-part-of-the-same-form
2. They are engineered to enforce archetypes - Generally, order sets are found in the order set section of the software, documentation is found in the documentation section, and guidelines and protocols may not be contained in the software at all. So while you can link from your clinical documentation TO your order set, or link your order set to a set of clinical guidelines, you can't actually put documentation and orders in the same part of the software.
3. Taking advantage of good, electronic Clinical Decision Support (CDS) generally depends on a clear, linear workflow.

Interestingly, most EMRs will still allow you to make orders, order sets, or documentation to address two or more different scenarios - While it's quite not as unorthodox, it still can lead to very lengthy documents/order sets with poor decision support that can frustrate users in the long run because they require a lot of clicking to complete them.

So let's now look at these three different types of Frankenforms in a little more detail.

C. THE "TWO DIFFERENT ROLE" FRANKENFORMS

A common workflow challenge is when two different roles are involved in ordering/documenting in the same workflow. The classic example of this is the Dietary TPN order, which is usually one order with many fields - Some are filled out by the physician, and some are filled out by a Registered Dietitian. 

You can often spot these forms because they have multiple signatures on them. While it's important to have both signatures before processing the order (often for safety/billing reasons), having two different signatures can cloud the workflow that led to the completion of the order - Who filled out which field? Did the dietitian enter the potassium, or did the physician? If the potassium needs to be raised, who does a nurse call? The physician? Or the dietitian?

Fixing these, to make them electronic, can be very complicated - and often means a good deal of workflow analysis and redesign. The electronic solution will typically have electronic orders and documents with electronic co-signatures, but will often mean a more rigid workflow (e.g. having to decide who starts off the workflow, the doctor or the dietitian? And who cosigns the order? And how do they attribute the cosignature to the right person?)

D. THE "TWO DIFFERENT ARCHETYPE" FRANKENFORMS

This is the scenario where a paper form with one signature actually contains components from two different tools, e.g. an "ED Nursing Protocol" which is part-documentation, part-orders, and part-guideline. Again, these were very convenient in the paper world, because you could have all-the-information related to the workflow in one place. 

While these are sometimes easier to build in an electronic environment (provided they really only have one stakeholder), they still generally require separation of the tools into their electronic components - E.g. the documentation in one place in the software, LINKED to the guidelines for review, LINKED to the orders that get activated. 

Often, while dissecting these Frankenforms into their separate components, workflow questions arise which must be looked at to ensure safety and regulatory compliance. Again, this is usually not hard to overcome, but it should be expected that converting these paper forms to an electronic workflow will take some additional time and resources. 

E. THE "TWO DIFFERENT SCENARIO" FRANKENFORMS

(Also sometimes referred to as "pick lists") - While this Frankenform looks fairly innocent (who wouldn't want all of their antibiotics on one order set?), it's generally a sign of a larger workflow issue. These Frankenforms, seeking to address many-different-clinical-scenarios-with-one-tool, can require the most time to redesign because they usually raise larger workflow questions, bigger than the form itself.

For example, having a broad "ED Antibiotics Order Set" means you are missing opportunities to develop disease-related, evidence-based order sets, which often involve more than just antibiotics. While in the short-run, physicians may like having all of their antibiotics in one place, they may get frustrated looking for other medications related to disease management, and/or miss other quality indicators. 

The solution to this type of Frankenforms is generally the construction of a larger library of disease-related, evidence-based order sets, focused on common disease pathways that doctors are responsible for initiating after they reach a diagnosis. (And so you might even want a separate library of order sets used to work up common chief complaints, to help them reach this diagnosis!)

While creating (and maintaining!) this larger library can take time and resources, it generally results in shorter, disease-related order sets, which are focused on the total management of the patient in an evidence-based manner, with better decision support, better provider satisfaction, better quality compliance, and better overall time savings. 

F. HOW TO FIX FRANKENFORMS

If 'going electronic' means that you will need Informatics resources to identify and fix existing Frankenforms, then budgeting for a successful EMR implementation generally means : 

• Conducting a complete review of all current clinical documentation and forms.
• Developing a good understanding of your current workflow issues by estimating the number (and type) of Frankenforms currently in use
• Planning and budgeting for the informatics resources necessary to fix (and maintain!) your solutions.

And so the first step in solving these issues is finding an experienced Informatics or workflow professional, and asking them to do a good current-state and needs analysis. The answer will help determine your success and satisfaction with your new EMR implementation!

I hope this post has been helpful in creating understanding and clarity. Thank you so much for reading my blog, and many happy wishes for 2016!

Have any thoughts about workflow redesign and optimization? Leave them in the comments section below!

Cutting Healthcare Costs by Making A Better Brick

1. THE BRICK

An interesting question I get asked is, "Why don't all order sets look the same at every hospital, even for the same disease?"

This question can be posed in several other ways, including :

1. "Why can't we just use order sets from someone else?"
2. "Why can't we just use canned order sets without editing them?"
3. "What do your policies look like?"
4. "Why can't we just use canned policies?"
5. etc...

But all of these basically ask the question, "Why isn't this standard?" and, of course, the follow-up question is, "Why is every hospital re-inventing the wheel?".

For inspiration to answer this question, I'd like to first explain a little bit about a wonderful thing : The brick.

According to the Wikipedia article, bricks have been in use since about 7500 BC to help construct things. (It's actually a really interesting article - If you appreciate human civilization, the brick has played a big role in building our streets, aqueducts, houses, walls, etc...)

The reason the brick is such a useful thing, from a design standpoint, is because it has two features :

1. A brick has a fairly predictable shape that allows you to easily arrange them to connect two or more places in space.
2. A brick is designed to withstand a particular load.

You'll notice these two features are helpful when designing any system - Having basic units engineered in a predictable manner, which can be assembled to make a bigger, more complex system that achieves a certain goal.

Hospitals contain systems that are also made of smaller units - Order sets are made of orders, clinical pathways are made of order sets, charts are made of notes, policy manuals are made of policies, etc. 

Unlike a physical brick, however, all of these basic units are conceptual - They are mostly complex documents - not physical objects - so it's a little harder to tell how predictable they are - e.g. to know if they're not engineered exactly the same.

For example, with physical bricks, it's much easier to tell if one hasn't been engineered exactly the same as the others :

You can immediately and obviously see the entire system is off, and locate the offending brick quickly.

But real bricks are not 100% predictable - They all have some degree of imperfections between them -As a kid, I occasionally ran into bricks behind our grade school, or around landscaping projects - I think I could only stack about 10 of them on top of each other before they start to fall over. (Legos are about the only bricks I can think of that are engineered to such a high standard that you can stack virtually hundreds of them on top of each other and still have practically a straight wall.)

But because regular bricks in the real world have subtle imperfections, humans have developed a tool we can use to compensate for these imperfections : Mortar, or cement.

Mortar/cement only works, however, to help straighten out the system when our brains get involved - We see the system leaning, so we set up guidelines/markers to help determine what is straight, and we put down the mortar/cement to compensate and correct the system. Again, the compensation depends on our human brain.

Because documents are not physical objects, we may not see the system leaning - But it can lean the same way in a conceptual manner. Fortunately, our brains can still compensate for a lot of conceptual leaning. 

So in my job in clinical informatics, I look at the standards by which the "document" bricks are built - To determine just how standard they are, and how much people's brains are compensating.

And this is why hospitals all have order sets that look and behave slightly differently - Because there aren't national standards by which their bricks are engineered. Fortunately, human brains are filling in the mortar.

What would it take to get all hospitals to engineer exactly the same bricks? The same engineering standards at all hospitals. 

And what would it take to get all hospitals to engineer bricks as well as Legos? An engineering process that was detailed enough to ensure that every brick looked virtually identical.

So why don't all hospitals have the same engineering standards and engineering process? Because documents, unlike bricks and Legos, are not as easily understood/studied/observed as physical objects. And because, for better or for worse, human brains can compensate extremely well - So there is little pressure to engineer them exactly the same. 

So as a result : Every hospital is re-inventing the wheel when it comes to their processes and their documents. In almost every hospital, they are looking to achieve exactly the same goal (in brick terms, "bear the same load") - Delivering standardized but customizable, evidence-based, high-quality care. But because the engineering standards and processes are not defined nationally, their tools are all ever-so-slightly different, and so virtually every hospital has to engineer them slightly differently.

2. A NEW IDEA ON CUTTING HEALTHCARE COSTS

The number of people employed to re-engineer all of these tools is remarkable. And it doesn't just include order sets - It includes every document in a hospital, virtually everything I mentioned in the CMIO's Checklist - Order sets, policies, protocols, documentation/forms, templates, etc. And all of these tools have to be continuously updated to reflect best practices, new technology, new evidence, etc.

These operations have become part of the price of healthcare - Continuously re-engineering all of these tools, so that the front-line doctors and nurses have the best and most up-to-date :

• Policies and Procedures to learn from and operate by
• Orders to take care of patients and deliver care
• Order sets to standardize and expedite the ordering process for a common clinical scenario
• Clinical Pathways to standardize care for a common clinical diagnosis
• Protocols to standardize and automate care for a common clinical scenario
• Guidelines to help standardize outcomes for a common clinical scenario
• Documentation tools to record and transmit data about care, and guide their thinking
• Templates to help them standardize and expedite the documentation process
• etc...

Unfortunately, keeping up with all of this information, and managing it, is very challenging for most hospitals. The professional industry term for this is "document management", and hospitals that do this well will probably have an easier time in the next five years than hospitals that do this poorly.

So to help hospitals struggling with this, I have often wondered why nobody publishes national, standard definitions of these tools, so that we could at least have the same engineering standards, and maybe then the same engineering processes - So that the order sets would all look the same - And you could truly use the same order set at any hospital...?

I suspect the reason that no regulatory body currently wants to offer these standard definitions is this : Anyone who tries to introduce these definitions and engineering standards nationally will have a big operational and financial challenge : 99% of hospitals would suddenly have to re-tool all of their documents to meet these national standards. Imagine the cost to healthcare nationally.

But so then I wondered - could we do something like this on a much smaller basis, in a much slower, more controlled manner?

Again I'll mention our Interstate 91 Informatics project - Where a bunch of volunteer Informaticists along the Interstate 91 Corridor here in New England are starting to meet regularly to talk about our common informatics issues. As I mentioned in a previous post ("Can we do better than SOAP?"), we are going to start talking about ways to standardize our documentation on a regional level. I'm interested to hear people's responses because it could be very interesting if, in the next step, we looked at standardizing our definitions, engineering processes, and engineering standards. Would it allow us to share resources that ultimately saved all of our hospitals money, and reduced the cost of operations and care in the entire region?

Stay tuned!

My belief is that we are all both teachers and students our entire lives - So I love to hear people's feedback and thoughts. Feel free to leave comments or questions - Always glad to entertain any new or interesting ideas!