Saturday, January 30, 2016

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!

Wednesday, January 27, 2016

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!

Tuesday, January 12, 2016

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!

Wednesday, January 6, 2016

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?


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!