How to write gourmet policy and procedure

Hi fellow informatics junkies, workflow managers, and other clinical Jedi,

I love watching the Food Network channel. Not only because it lets you watch world-class chefs prepare unbelievable dishes, but because of the business and operational lessons they sometimes impart. Two of my personal favorites are Gordon Ramsay and Buddy Velastro, who not only bring a real love for food, but also demonstrate really smart business and operational sensibilities. I have always believed that healthcare could learn some lessons from the food industry.

With that in mind, today I'd like to address the subject of policy writing. To me, policy is like food -  If you don't like it, and it doesn't nourish you, why bother with it? It's not just enough to taste good - Good policy should also be good for you. 

Also, like food - Good policy creates harmony and brings people together. Holiday dinners are no fun to make if you are the only person making them. They become much more meaningful when you share the labor with your family, and have a chance to talk and communicate while you wash the vegetables and boil the pasta. The same applies to policy writing : It's not just the end result that matters - It's also the road you travel to get there. 

Writing great policy and procedure doesn't have to be painful - It's actually fun once you know the recipe. It can help you create clarity, harmony, and efficiency. So with that in mind, I'd like to offer up a great recipe: How to write a gourmet policy and procedure.

Now remember, because they can become the subject of legal inquiries when they fail, policy is something you should take your time to develop. For this reason, you'll also want to consult your legal advisor before undertaking any changes to your policy process.

Also remember, procedures are workflows - So by writing good policy and procedure, you are mapping out your core operational workflows! If you have an EMR and an Informatics team, you can save lots of time by making sure your procedures are well-written, since they are key tools used to configure your electronic medical record!

Now, before we get to the recipe, just so we're all on the same page - what's a policy, and what's a procedure?

• POLICY = Your standard
• PROCEDURE = How you will achieve that standard

These two are often found together on the same document, because once you define something as being a standard (policy) in your organization, you will quickly need to know how you are going to meet that standard (procedure).

This is where a common question comes up - Q:"Do you NEED to have the procedure on the same document as your policy?" A : No. Some organizations choose to just define policy - And then link the policy statement to a separate procedure document, e.g. "PROCEDURE : Please see the Lippincott Manual, page ____". Either way, if you are defining a policy standard in your organization, that you can legally be responsible for upholding - you should put a lot of thought into how exactly you will uphold that standard. 

Now - Let's get to the recipe!

A. PREPARATION :
The first step to creating a policy is asking the question, "Do I really need a policy?" You generally don't need to create policies for things that are common sense, don't benefit your organization, or impossible to enforce. On the other hand, you *do* want policies for the important operations of your organization, especially ones that are supported by regulations.

Once you've decided that you need a policy, the next step is doing some literature search, starting with your existing policy manual - Does any existing policy already address some or all of the desired standard? You will need to do this to ensure you don't have overlapping or conflicting policies. You will also want to review other current literature, to see if there are any regulations, studies, or best-practices which support the creation of your policy.

If there is no conflicting policy, then next it's helpful to gather the organizational policy template, policy style guide, and any regulations or articles you've found which support the creation of the policy. 

B. DRAFTING THE POLICY :
Once you have clarity on your need for a policy, including the regulations and any other citations which support the creation of the policy, you will want to then take your standard policy template and policy style guide, and start to write the policy statement.

Policy statements, ideally, are short and sweet, and should clearly state what your desired standard is. An easy way to think of writing them is using this template : 

"All __________ will _________ according to the procedures outlined below."

So, as a teaching example, let's make a "Cupcake policy" that makes it mandatory for all patients to get a cupcake on arrival to an inpatient bed : 

Now that you have drafted the policy statement, you will want the reader to figure out how they can achieve this standard by writing a good procedure.

C. DRAFTING THE PROCEDURE (with time/cost/labor estimates!)
To help support our new cupcake policy, we will want to figure out exactly how the organization will support this policy. This is the place where organizations can save a lot of time and money by writing a great procedure that helps create harmony during the policy review process. Remember - procedures are workflows, and working them out regularly will help create workflow clarity, making your policies tools of budgeting, education, and harmony.

The easiest way to write a clear procedure is to use the following template : 

[ WHO ] will/may [ WHAT ] [ where ] [ how ] [ when ] [ why ] [ time ] [ labor ] [ materials ] 

Where : 

• [ WHO ] = Role of the person who will perform this step of the procedure
• [ WHAT ] = Task they will do at this step of the procedure
• [ where ] = (OPTIONAL) Where they will perform this task (e.g. "in a bowl")
• [ how ] = (OPTIONAL) How they will perform this task (e.g. "with a spoon")
• [ when ] = (OPTIONAL) When they will perform this task (e.g. "until smooth")
• [ why ] = (OPTIONAL) Why they perform this task (e.g. "to prepare for baking")

So for our cupcake example, we might start by DRAFTING the following procedure : 

You will notice that by writing it using this template, you have started to answer some questions : 

• Who are the end-user stakeholders? (A: Kitchen staff, couriers, and inpatient nurses.)
• Who will need to help review this policy? (A: Director of Kitchen Staff, Director of Couriers, and Director of Inpatient Nursing)
• What is the cost of this procedure? (A: Time, labor, and materials of each step!)

In fact, if you wanted to get really fancy, you could potentially bring this procedure into a spreadsheet, and calculate the cost of the procedure to a penny!

I highly recommend playing around with your procedure in a spreadsheet like this - You will quickly figure out two things :

• How much, exactly, the policy will cost you (in this case, $326.40/day in materials and labor x 365 days a year = $119,136/year!)
• Where you might be able to save costs in this workflow (e.g. asking a courier to pass out the cupcakes, instead of inpatient nurses, could save you $80-$20=$60/hr savings x 3.33 hours = $200 savings a day x 365 = $73,000 savings/year!) 

Figuring out this cost will help prevent you from approving a policy that you don't have the resources to follow. And once you have this procedure (workflow) worked out to your satisfaction, you can then add the regulations/citations which support the creation of the policy : 

... and bring this DRAFTED policy to the stakeholders for review.

D. DETERMINING THE STAKEHOLDERS
Because this procedure was written with the above template, it's pretty easy to figure out who needs to review this policy before it's brought for final approval - The people responsible for the people who will do the task, usually something like : 

• The Director of Kitchen Staff
• The Director of Couriers
• The Director of Inpatient Nursing

So you will want to add their names to the "Reviewed By:" section of the policy (see below):

... and set up some time with these people to review the new policy. 

E. MEETING WITH STAKEHOLDERS TO REVIEW POLICY
Once you meet with these stakeholders, you will want to review the policy together and ask them three questions : 

1. Can your staff do the task(s) in this procedure?
2. Do you have the budget to pay for the staff to do the task(s) in this procedure?
3. Can you educate the staff to perform the task(s) in this procedure properly?

If the answer to any one of these questions is "NO", then it means that either the policy should be edited, rewritten, or delayed until issues can be resolved.

If the answer to all three of these questions is "YES", then ideally, you would seek their signature under the "REVIEWED BY:" section of the policy : 

In some organizations, you might need to seek additional signatures under the "Reviewed By:" section, such as a person from quality to review the policy name and coding are correct and that the spelling and citations are all correct. To see if there are additional signatures, you will want to refer to your organization's standard policy process, usually kept by your policy coordinator.

F. BRINGING FOR FINAL APPROVAL
Once you have the signatures required for final approval, you will again want to refer to your organization's standard policy process, and arrange for the policy to be approved and published. 

Ideally, there is only one signature required for approval, so that the policy can be briefly reviewed in a committee, approved by vote, and then whoever is authorized to approve policy for the organization then signs it, making the policy an active policy : 

Sometimes, usually for political reasons, some organizations have decided to require two signatures for approval, to create a system of checks-and-balances. While this is sometimes helpful, it can also delay policy approval if you don't have both people in the room at the same time. (E.g. one person might agree to sign the policy after a committee vote, but then the second person later decides not to sign the policy = This ends up delaying the approval and frustrating the committee.)

G. PUBLISHING YOUR POLICY
After approval, the person with authority to give final approval should then follow your organization's standard policy process to make sure that the policy is correctly indexed and published in the organization's standard policy manual.

Sometimes, policies will contain an "ACTIVE DATE:" in the language, to allow for policies to be approved before they become active (e.g. approving a policy in February for a project that goes live in March). If the policy clearly states the "ACTIVE DATE :", then you can place it in (or upload it to) your policy manual before the actual active date. 

When a policy is published to your organization's manual, you will now want to send a notice to the people who will be expected to follow the policy - In this case, the kitchen staff, the couriers, and the inpatient nurses.

Finally, you will want to make sure the stakeholders actually educate their teams about the new policy, and assemble whatever resources are necessary to start the new workflow on the expected start date.

H. MONITORING YOUR POLICY
Policies should be monitored for effectiveness by the stakeholders, as soon as they are approved and published. Sometimes the question arises, "What if someone breaks a policy?". While this is a problem, it should not mean immediate punishment or remediation. Instead, it should trigger an inquiry and discussion of what-went-wrong : Was the policy incorrect? Not educated properly? Not budgeted properly? Incorrectly written?

If the inquiry reveals no problem with the policy, then usually it is just a matter of some re-education or remediation, to correct the issue. This deficiency should still be tracked and noted for future review of the policy.

I. REVISITING YOUR POLICY
Policies should be reviewed at least every 2-3 years, to ensure that they are still effective, properly educated, and properly budgeted for. Sometimes organizations make budget changes that impact policy function - Ideally, you will want to catch those workflow changes as soon as possible, but by making it a habit to revisit your policy at a minimum of every 2-3 years, it will help make sure that your policy is accurate, functioning, and up-to-date with current regulations.


Remember - Good policy reduces cost and creates operational clarity and harmony. Bad policy does the opposite. Always review your policy needs, make sure you don't already have an existing policy/conflict, and review your organization's standard policy process and template before you start writing!

Finally, a great reference (for those seeking more information on policy writing) is Writing Effective Policies and Procedures : A Step-by-Step Resource for Clear Communication by Nancy J. Campbell (1997). It's a big book, but the first few chapters are fantastic in explaining the basics, and the rest of the book is a great reference for how to tackle more complicated policy issues.

I hope this has been a basic, helpful review of policy and procedure development! Always ask your policy coordinator and legal counsel for advice before making any changes to your current template or process! Feel free to leave your thoughts and feedback in the comments below!

What is your EMR documentation index costing you?

It's all about the details. One of the things that I really love about front-line clinical Informatics is the remarkable insights you get into clinical operations - and how the tiniest, seemingly trivial design elements can strongly influence the cost and quality of patient care, as well as the cost of maintaining your EMR. 

When I first started, I didn't fully understand this relationship, and the focus of my attention was less on the names of notes and order sets, and more on their content. Fortunately, a respected Informatics colleague gave me this advice, early on :  "If you haven't struggled with designing a naming convention or a documentation index, you haven't done your job." 

It took me a while to understand exactly what this meant, but through years of experience, it's become much more clear to me. So for educational purposes, I thought I would share the story of how I was recently reminded of this lesson, when I saw the following posting on a popular Informatics listserver (paraphrased here for brevity):

'I would appreciate your input on the approach you have taken to your folder or ‘hierarchy’ structure for documentation mapping.
We have robust use of our EMR in both the inpatient and outpatient setting. I have seen both ends of the spectrum when it comes to hierarchies:  Minimal number of note types to a very high level of specificity. We fall in the latter category and are always looking for ways to streamline and strike the right balance. Can you share the approach your organization has taken in this space? 
This may, in part, depend on how robust the search tools are within each EMR but I have some basic questions:

• Do you have Outpatient notes separated from Inpatient Notes?
• Do you separate notes by medical specialties?
• Do you distinguish between a Resident and a Staff note? What about a Medical Student Note? (Do you take an alternate approach to distinguish between these such as the ‘signature line’ in the note proper or the template used for the note?)'

My response reminded me about how much the years of experience had taught me about designing naming conventions and documentation indexes. My paraphrased response is below : 

[ START OF RESPONSE ] 

This is a great question! You have a great opportunity in front of you - This is the essence of what we do - Make it intuitive for people to understand and find their notes in the vast sea of information that is an EMR!

I’ve never been given the same challenge (although it would be a good one!), but I think I would start with a few guiding design principles : 

1. The name of the note should follow a standard naming convention.

2. The index of the note should be intuitive enough for both users and managers to be able to quickly find the information they need.

With those principles in mind, I might then use the Bell Labs North American geographic telephone number model (e.g. (xxx) xxx-xxxx (area code - prefix - identifier)) for paradigm inspiration, and start by [DRAFTING] an index like this: 

Document Name = [ Geographic level-of-care ] + [ Setting ] + [ Role ] + [ Name of note ]

Where :

• Geographic Level-of-care = Where the patient is registered, e.g. Inpatient or Outpatient,
• Setting = What unit the patient is registered in, e.g. Med/Surg, Cardiac Telemetry, ICU, Childbirth, Nursery, Pediatrics, Psych/Behavioral Health, etc
• Role = Role of the documenter, e.g. Adult Hospitalist, Pediatric Hospitalist, Intensivist, ED Nurse, ICU Nurse, Med/Surg Nurse, etc.
• Name of Note = Common name of note, e.g. Admission H&P, Daily Progress Note, Discharge Summary, Consult Note, etc.

So, for example, you could use this naming convention to design a document index like this :

• Inpatient - Med/Surg - Adult Hospitalist - Admission H and P
• Inpatient - Med/Surg - Adult Hospitalist - Daily Progress Note
• Inpatient - Med/Surg - Adult Hospitalist - Discharge Summary
• Inpatient - Med/Surg - Adult Hospitalist - Medical Consultation
• Inpatient - Med/Surg - General Surgeon - Admission H and P
• … etc…

The reason I would probably avoid specialty, and instead use role, is because some specialties fill multiple roles (e.g. Med/Peds specialists might work one day in the role of an Adult Hospitalist, and the next day in the role of a Pediatric Hospitalist) - 

So if you decide to use this format, then, the strategic question will become : What exactly is your organization's list of roles? 

• The more roles you have, the more expensive it will be to maintain your documentation, but the happier your docs will be having documentation designed just-for-them, and the easier it will be to collect role-specific quality indicators.
• The less roles you have, the cheaper it will be to maintain your documentation, but your docs may not be as happy having to accommodate to a one-size-fits-all approach, and the harder it will be to collect role-specific quality indicators.

So you will need to strike some sort of balance between the two. On the most cost-effective, conservative side, you might have very generic roles like : 

1. Inpatient - Med/Surg - Attending - Admission H&P
2. Inpatient - Med/Surg - Attending - Daily Progress Note
3. Inpatient - Med/Surg - Attending - Discharge Summary
4. Inpatient - Med/Surg - Consultant - Consult Note

And in the happy-medium, make-the-docs-happier and collect-more-role-specific-quality-indicators range, you might have roles like : 

1. Inpatient - Med/Surg - Adult-Hospitalist - Admission H&P
2. Inpatient - Med/Surg - Adult-Hospitalist - Daily Progress Note 
3. Inpatient - Med/Surg - Adult-Hospitalist - Discharge Summary
4. Inpatient - Med/Surg - Adult Hospitalist - Consult Note

And finally, on the most-expensive, docs-might-love-it-but-nobody-can-afford-it side, you might have roles like : 

1. Inpatient - Med/Surg - Adult-Hospitalist - Dr. Stanley - Admission H&P
2. Inpatient - Med/Surg - Adult-Hospitalist - Dr. Stanley - Daily Progress Note 
3. Inpatient - Med/Surg - Adult-Hospitalist - Dr. Stanley - Discharge Summary
4. Inpatient - Med/Surg - Adult Hospitalist - Dr. Stanley - Consult Note

For provider satisfaction reasons, I generally wouldn't recommend the first approach, and for cost reasons, I generally wouldn't recommend the third approach. Naming conventions and document indexes with provider names means you will be spending a lot of time and resources maintaining a much larger set of order sets or documentation than you might have budgeted for.

Whatever strategy you decide to employ, you will be living with the decisions for a long time, so I recommend really spending some time, drafting your naming convention and documentation index, and present it to both your clinical and administrative leadership for approval, before moving forward.

Hope this helps! Good luck!

- Dirk :)

[ END OF RESPONSE ] 

So gradually, you start to learn how these tiny, seemingly trivial design details impact the cost of care and maintenance of your EMR, and so you look out for them and look for ways to help cut costs and still maintain provider satisfaction. 

Please note : Other responses to this question included recommendations about using LOINC coding standards to assist with developing industry-standard file naming conventions. This is great advice, and helpful in achieving documentation harmony, especially if you are planning on a HIE or exchanging documentation with other organizations. You can read more about LOINC by going to their web page : 
http://loinc.org/international

Anyway, this was just a very basic introduction to some EMR design issues, and how they impact the cost of EMR maintenance - but I hope this story will be helpful to you in tackling your own naming convention and documentation indexing challenges!

Clinical Linguistics and EMR Interoperability

Hi fellow Informaticists, CMIOs, CNIOs, and other #HealthIT enthusiasts,

For today's post, I wanted to muse on a favorite subject : What can language management teach us about design of clinical documentation and EMR interoperabilty?

To answer this, it's helpful to first understand the three common models of communication used in clinical settings : 

1. Synchronous Communication - Undocumented, real-time communication, where both sender and recipient are sharing the same moment in time - E.g. face-to-face conversations, telephone conversations, video chats, or meetings
2. Asynchronous Communication - Documented communication, where both sender and recipient are separated in time - E.g. EMRs, HIEs, Notes, charts, graphs, videos, recordings, videos, voicemails
3. Hybrid Communication - Shares features of both, e.g. Texting, social media, Twitter, recorded phone calls, etc.

Professional interpreters and translators (like you might find at the U.N.) have worked for years to manage communications across these models - What can healthcare learn from them?

To help answer these questions, I've developed the following 14-minute-3-second video, for your consideration : 

I hope you enjoyed it - Leave your thoughts or feedback in the comments section below!

Problem Lists - What exactly is the "Past Medical History"?

Hi readers,

Happy 2016! For today, I'm going to try to tackle an interesting conceptual and terminology issue around problem list management, and how it relates to the Past Medical History (PMHx).

Many people, working to optimize their EMRs, work hard to try to 'curate the problem list' - WIthout good curation, problem lists can become very lengthy, and include issues like "Cough" under Past Medical History - 

1. Some people see this as a failure of HealthIT ("Why is cough under the Past Medical History, when it's not a diagnosis?") - 
2. Other people see this as a failure of the doctors using the system ("Why didn't anyone remove cough from the Past Medical History?") - 

What I find particularly interesting about this discussion is the wide variation in practice, when I read admission history and physicals. I think most docs, billers, and coders believe that, on admission, the doctor should document whatever the 'acute medical issues' or 'active medical issues' are - But what do these terms mean, exactly?

1. If a patient with stable diabetes is now admitted with cellulitis, and the doc continues the diabetic medication - Should diabetes be on the active medical issues list?
2. Or should the doc only code for the cellulitis?

In discussing this many times over the years, I find that many docs use the terms 'active medical issues' and 'acute medical issues' almost interchangeably. Are they really interchangeable?

So I Googled the terms "Active Medical Issue" and "Acute Medical Issue", and found a number of good articles, including this 2010 post by A Country Doctor on Kevin MD and this excellent 2005 discussion on Past Medical History by John Gazewood, MD. Finally, the US National Library of Medicine offers this good explanation of acute versus chronic conditions.

But how are acute and active medical issues different? While these are are all good treatises on medical issues, I was wondering if I could approach this from a design standpoint, as a physician informaticist, with good conceptual definitions for the terminology, to make sure there is real clarity around the discussion. 

So, in trying to tackle this informational design issue, I've hammered out the following DRAFTED definitions, depicted on the following two slides, for your examination and discussion (the same concepts are on both, but each is displayed slightly differently) :

Slide 1 - "Bucket" depiction

Slide 2 - Same concepts, different depiction

I created these slides to try to create conceptual 'buckets' that problems/issues could easily fall into, allowing physicians to move items from one bucket to another as the patient moves from one provider to another - And then labeled them with terminology (and synonyms) that I believe best fit the concepts. (Please use your own judgment before adopting any of this terminology.)

What these slides do, however, is shed some light on why maintaining the problem list is more challenging than you might expect. It requires enormous clarity just to discuss the issues, and then when you examine the concepts in detail, there seems to be some breakdown in the definition of "Past Medical History". 

For example, in the scenario where the patient with stable diabetes is admitted for cellulitis - On writing the admission H&P, a doctor might code for both the Unstable (Acute) issue ("Cellulitis"), and the Stable (Chronic) Issue ("Diabetes, Type 2, Controlled"), since he/she has made the active medical decision to continue the diabetic medication while treating the cellulitis. 

However, on discharge, what do you do with these two Current(Active) issues (Stable and Unstable) in the EMR? 

• The cellulitis might be moved to the Prior(Inactive, Resolved) Issue list, but 
• the diabetes is still a Stable (Chronic) issue - which falls under the category of Current(Active) issues - 

So the problem is that, I suspect, most doctors would conceptually define "Past Medical History" as the items found in these three buckets : 

1. Prior Procedures
2. Prior (Inactive, Resolved) Issues
3. Stable (Chronic) Issues - which conceptually falls under the category of Current (Active) Issues - 

It's the incongruence between "Past Medical History" and "Current (Active) Issues" that I find most interesting - Past isn't really in the past, if it's still in the present. 

It's also interesting to note that the commonly-used term "Reason for Admission" typically only includes issues that would fall under the Unstable (Acute) issues bucket - But the Admission H&P typically includes more issues, especially if they involve active medical decision-making (E.g. both Unstable (Acute) issues + Stable (Chronic) Issues)

In practice, I find many docs will only include as many Stable (Chronic) issues as time (and patient census) allows - It's interesting to ponder how this impacts coding and billing on the national level.

Finally - I believe these slides support the argument that the terms "Active Medical Issues" and "Acute Medical Issues", although related, are in fact not interchangeable. (I suspect that Acute is really a sub-type of the concept of Active medical issues.)

While my post today doesn't have any great answers, I hope these slides, and this discussion, have at least shed some light on the concepts and terminology surrounding problem list management, and how they impact EMR usage, coding, and billing on the national level.

Have any thoughts about problem list management? Leave them in the comments section 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!

Informatics Domain and Clinical Workflow Video

Hi readers,

After my last post, some people asked me if I could put it into a video form, to help share with other people.

I was able to condense it into this 7-minute, 23-second video below.

So for anyone who has ever struggled to explain the Informatics domain, how it is related to clinical workflow development, and how it can help create smooth, predictable, reliable, and non-disruptive workflows - I offer up the following : 

Hope it was helpful! Leave your comments and feedback in the comments section below!

The Informatics Domain and Workflow Management

Hi readers,

For today's post, I'd like to offer some insight about two common questions I get - What is clinical informatics, really? And just how is informatics related to workflow development in the EMR world?

So to really answer these questions, I'd like to propose three goals for this post :

1. To describe how operational tools and workflows are developed and directed in an organization.
2. To describe the informatics domain.
3. To demonstrate how the informatics domain is vital in developing and directing workflows in the electronic (EMR) realm.

And by accomplishing those goals, I hope I can offer some insights into how to build a successful informatics platform. So, let's start off with a diagram I have lovingly named the "operations pyramid" :

I created this diagram to help explain how predictable operations are created. First, let's look at two important features of the diagram : 

1. At the top is the Mission/Vision - This is essential for setting the tone and direction of the organization, creates goals and targets, and is necessary to align the rest of the operations with successful outcomes. Typically, senior leadership has the responsibility for defining this very important part of the operations pyramid.
2. At the bottom is the Organizational Support - Because nothing happens in an organization without good support.

Between these two parts of the pyramid are a number of steps which all build on each other to predictably support the Mission/Vision of an organization. First - From the bottom-up, let's step through them - The : 

• Organizational Support (needed for everything) helps create the...
• Concepts (or in Informatics lingo, Ontologies) which shape the fundamental understanding and principles that the the organization uses to function, which then supports the... 
• Definitions / Terminology / Standards the organization uses to write and speak predictably to each other, which then support the...
• Templates / Archetypes the organization uses to support the creation of predictable...
• Documents / Tools which the organization uses to support the...
• Workflows / Processes the organization needs to support the ...
• Goals / Regulations the organization seeks to support the ...
• Mission / Vision of the organization.

Even when it's not fully appreciated, every organization has this pyramid at work, creating predictability and infrastructure - or not, if it's not well-understood.

This brings us to the Informatics domain, and why it's suddenly become an important part of operations in the EMR world. Informaticists are people who work to create predictable outcomes by focusing their attention on parts 3-7 of this pyramid : 

So to be successful at creating predictable workflow/process outcomes (#3), Informaticists must also concern themselves with steps 4-7.

Now, keep in mind that the part that's most visible in most organizations - the traditional documents/tools (deliverables) that we think of as 'what we need to operate' (e.g. documentation, order sets, etc) - is really only step 4 in this pyramid :

So you'll notice that in the entire Informatics domain, these documents/tools that are seen as the traditional deliverables are only small piece of the domain :

... and so conflicts can arise if it's not well-understood :

1. ...that these deliverables are only a piece of the entire Informatics domain, and
2. ... the depth/breadth of these of deliverables. 

So to better understand the challenges organizations may face when developing a successful Informatics framework, let's look at this line #4 (Documents/Tools) in a little more detail, and see how it related to workflow development.

To create workflows that are smooth, predictable, reliable, and non-disruptive, requires a significant amount of deliverables - The list continues to grow as technology advances. One common source of confusion : Only some of them are inside the EMR, which is another potential source of conflict for the Informaticist who is seen as only needing to occupy their time with the 'EMR issues'. So let's look at these deliverables in more detail : 

In the above slide, I've largely separated the workflow deliverables into :

1. The ones generally outside the EMR are ones that are traditionally seen as the responsibility of other departments, such as quality, nursing, IT, HR, or finance. (e.g. policies/procedures, guidelines, interfaces, schedules, etc.)
2. The ones generally inside the EMR are ones that are traditionally seen as the responsibility of Clinical IT/informatics departments (e.g. clinical documentation, orders, order sets, etc.)
3. The ones that span both (largely the emerging workflow technology which is created to help automate clinical workflow management).

The challenge that some organizations face in developing a successful informatics platform, however, is the understanding that whether they are inside the EMR or outside the EMR, or both - These deliverables all impact workflow.

So to avoid conflict, it's important to consider breaking with tradition, and developing a newer governance model which integrates your informatics leadership with the leadership of these other departments (e.g. quality, nursing, IT, HR, and finance). If the workflows that the organization needs depends on all of the deliverables, together, then it's important that the leaders of all of these areas work together to manage these deliverables as a team.

And this is why informatics should not be confused with IT, tech support, or 'whatever's inside the EMR' - Workflow success depends on the integration of leadership from all of these areas, to ensure that the organization can build and fully support the workflows that are needed to support their operational goals and vision.

I hope this post has been helpful to you! Leave any comments or feedback in the comments section below!