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!

Why document management and archetypes matter

QUICK QUIZ : What do the following pictures all have in common?

San Cave Art, taken by Valroe at en.wikipedia [Public domain], from Wikimedia Commons

Graffitti in Northampton, MA, taken December 2012

  

Artwork from Thomas Stanley, age 4 (from Jan 2013)

ANSWER : They are all powerful reminders of the anthropologic relationship between human beings and their documentation. In other words, I think that very human attempt at self-understanding, expression, and communication :

... is still very much reflected in the organizations and businesses of today :

In other words, I think one way to help understand organizational dynamics is to see an organization as just many, many iterations of this same loop :

... by asking yourself :

• A - Who are the people in the organization?
• B - What are the documents in the organization?
• How do A and B interact?

This is why document management matters. Documents are tools - Every document serves a unique function.  So the way you manage your documents and information will, at least in part, determine the actions and behaviors of your employees, and collectively the functioning of your organization :

• Give them the right tools to express themselves, in the right way, at the right time - and you will empower your directors and managers to make changes in your organization. (WRITE)
• Publish those tools in the right place, in the right way, at the right time - and you will empower your staff to learn your values, beliefs, and operational standards. (READ)
• Update those tools regularly, and you will make sure that both your documents and employee behaviors are current, and reflect your ongoing changing needs. (GOVERNANCE)

And so, you want to make sure :

• Your managers/directors make the best tools.
• Your tools are published the best way, so people can easily find, read, and learn from them.
• Your tools are updated regularly.

What exactly are those tools? I outlined some common healthcare-related tools in the CMIO's checklist, but they vary from industry to industry. But what you *do* want to make sure of is :

• Each tool has a specific, well-defined purpose. (E.g. Apples=Sweet, Onions=Spicy)
• Your managers have clear guidelines about how to develop the tools (So they grow apples and onions, and don't build a hybrid apple/onion that people are confused by)
• You have some kind of quality check before tools are published (e.g. to weed out the occasional apple/onion hybrid.)
• Your front-line staff knows where to find those tools (so they know to find apples in the apple bucket and onions in the onion bucket) 
• Your front-line staff knows when and how to use those tools (e.g. apples for baking pies, and onions for making soups).

The reason I bring up the issue about hybrid tools is because, unlike real-world, physical tools - The engineering and safety of paper tools is not quite as intuitive.

For example, a hammer is fairly intuitive :

• It serves one purpose : To drive in nails. 
• Its safety is fairly intuitive : You can see it, touch it, and feel its weight, and once you hit your thumb by accident, you'll quickly learn how not to do that again. 
• Its utility is fairly intuitive : If the hammer doesn't successfully bang the nail in, you'll quickly know you need a bigger hammer. And it's fairly easy to see that you shouldn't use a hammer to put in a screw.

Paper tools are tricker. 

• It might not be as immediately clear if the purpose is vague, ambiguous, or serves multiple purposes.
• You might not immediately notice any safety issues, or know when the tools is malfunctioning.
• You might not quickly see if the tool isn't serving its purpose.

This is why it's important to ask yourself about how your paper tools are designed and used. For maximum efficiency, you'll want them to work the best they can - And that means not just designing good clinical documentation, but reviewing it properly, approving it properly, publishing it properly, and monitoring it properly.

Think of your paperwork as the lifeblood of your organization. If the blood doesn't flow from heart, to finger, and back to the heart - Then it's not doing it's job : To transfer information from the center to the periphery, and back again, in a continuous loop.

This is why document archetypes are important in healthcare - They are a big help when it comes designing your paperwork - Which can be a big influence with the READING part of the loop between your employees and your leaders.

SO WHAT EXACTLY IS AN ARCHETYPE?
This is one of those terms that Informaticists sometimes use, that can sound scary or weird, until you know how simple it is - and then it becomes very friendly and helpful.

According to Wikipedia, an archetype is a "universally understood symbol, term, statement, or pattern of behavior, a prototype upon which others are copied, patterned, or emulated..." Think of it as the mold you are going to use to cut your cookies - If you want round cookies, then it helps to have a round cookie-cutter :

• If you wanted a compelling hero template that could serve as a role model (template) for all heroes, to write a blockbuster science fiction movie, then you might make a superhero archetype and name the character "Luke Skywalker".

• If you wanted a compelling policy that could serve as the role model (template) for all policies, to have a blockbuster policy manual, then you will similarly need a superpolicy archetype to set the example for all of your policies.

(One quick unrelated side note : In this way, I think comic book superheroes actually benefit society - By creating templates/archetypes that kids can use to model at least some of their behaviors. I think this is also why it's unusually heartbreaking to see sports heroes sometimes fall from grace: We hold them up as archetypes of goodness, teamwork and fairness - and then feel great disappointment when we find out that they're actually only human.)

Anyway, having well-defined archetypes helps make sure that every document / tool serves a common purpose, and is developed, used, and monitored in a standardized way. It's that predictability that creates harmony, clarity, and efficiency in your organization.

So ask yourself - What are your documentation role models/archetypes? Perfection is near impossible, but you still probably want your documents to be pretty close to superheroes. Are they already superheroes, or do they need help? Once you have some super archetypes that your employees can use to model behaviors and communication, you will generally start to see a real improvement in your quality, operation, and efficiency. 

Remember, these posts are only for fun, education, and friendly discussion - Remember to check with your own experts and superheroes before you take any actions! And I'm always interested to hear people's thoughts and feedback, so feel free to comment below! :)

Hospital Administrator Informatics Tools

So it's been almost a week now, and I'm still trying to find good definitions for :

1. Clinical Protocols (to help automate a clinical process, e.g. Heparin or Insulin drips)

2. Clinical Policy

3. Clinical Documentation

4. Clinical Order Set

5. Clinical Templates

6. Staff Education Module

7. Patient Education Module

8. Clinical Staff Schedule

Each of these tools requires a delicate process to build, develop, approve, and publish them.

And the interesting thing? We don't seem to have a standard policy definition! The SKTM Glossary (http://www.skmtglossary.org) seems to offer mostly technical definitions, and various other web sites seem to have different definitions/labels for this very common tool in healthcare. (Most of the other definitions are related to clinical trials.)

I'm honestly surprised The Joint Commission and CMS haven't stepped in to offer a definition that could be very useful in healthcare policy development and educating healthcare administrators internationally. (Is anyone from CMS or TJC a reader? Email me!)

There are also a bunch of automated software packages and companies that provide automated policy management - Just Googling the options will give you lots and lots of choices. (This must be a big business!)

In the meantime, I keep trying to keep the Wikipedia entry alive :

http://en.wikipedia.org/wiki/Health_informatics_tools

(Perhaps I should write the first "Healthcare Administrator's Toolbook", so I can use myself as a citation?) :P :)