The Financial Costs of Hidden Protocols : How Regulatory Bodies Can Help

Know that very common tool known as the “Heparin protocol”? Whether your hospital is electronic, or paper-based, you probably have some version of it.

Take a good look at it. Is it titled “Heparin protocol”? Or “Heparin Order Set”?

Know the difference? Many people don’t. This is one of the hidden costs of healthcare that few people appreciate or understand.

A protocol is a document with a clear set of specific instructions, which allow a nurse, pharmacist, or other licensed medical professional to activate, modify, or discontinue a patient care order on behalf of the protocol. Any conditional (IF/THEN) statements should refer to well-described, discrete data elements. Protocols must be activated and deactivated by a physician order. Clinical protocols are commonly published internally in either an electronic or paper protocol manual.

An order set is a grouping of patient care orders (medication orders and other orders) to help expedite the ordering process for a common clinical scenario. Order sets are commonly published internally in either a paper printshop/order set catalog or an electronic medical record.

The problem is : Many hospitals confuse the definitions for these terms, and as a result, they engineer and publish protocols incorrectly. Instead of being published as protocols, they get designed, approved, and published as order sets.

Now look again at your order set. Are there any conditions that would make a nurse enter a new order, modify an existing order, or discontinue an order? “Discharge patient when criteria are met”, “This order should only be used in the ___”, “Advance diet as tolerated”, “If pain is uncontrolled, titrate IV to …” – Do you see any of those? If so, you may have protocols hidden in your order set.

Why is this a problem? Because protocols and order sets have different functionality, which brings unique engineering needs :

1. Order sets - Contain orders that are activated/modified/deactivated by a physician.
2. Protocols - Contain orders that are activated/modified/deactivated by a nurse/pharmacist. (based on a well-defined condition.)

The problem doesn’t just stop there. Protocols are sometimes confused with clinical policies.

A clinical policy is a written goal for a defined patient population. The clinical policy applies to the defined patients, from the time of approval to the time of discontinuation, both executed by an order of the President of the Medical Staff or an appointed chairperson.

A procedure is a written list of explicit instructions about how to achieve a particular goal. Procedures related to policy goals are commonly attached to policy documents and published in a policy manual. Procedures related to other goals are commonly published internally in either a paper or electronic procedure manual.

Now look at your clinical policies. Do you have protocols hidden in your policies?

What does this confusion cost a healthcare institution?

When the common clinical tools are not well-defined in hospital policies and charters, they can be poorly engineered. Poorly engineered clinical tools may not create their desired impact. This makes change management very challenging.

The cost of this confusion, unfortunately, generally goes unnoticed until an EMR (Electronic Medical Record) ultimately forces a hospital to contend with these definitions. In a paper world, the clinical environment will generally continue to function, even if the borders between all of these are blurry. In an electronic world, most software is not as forgiving as paper – Order sets appear in one place electronically, protocols appear in another, and policies appear in yet another. These may all need to be re-engineered to work electronically. (This is one of the reasons why hospitals see a performance benefit after they "go electronic".)

To contend with the management of these tools, even on paper, hospitals often designate committees to help review, approve, publish, and implement these tools. But because there are no widely-accepted standard definitions for these tools, the policies and committee charters that refer to these tools may be vague.

The net result : A committee that works to create a protocol, that mistakenly gets published as a policy, may not have the desired impact on front-line patient care. When this happens, the administrative costs of managing these tools can skyrocket, and those committees can feel powerless to make change. 

Why are there no widely-accepted standard definitions for these tools? Surprisingly, none of the common regulatory or standards organizations in American healthcare seem to publish nor endorse common definitions. So where did the above definitions come from? I wrote them.

As a result of this lack of definition, hospitals are forced to contend with these engineering issues individually. Some will navigate this easily. Others will not.

My recommendation would be for CMS and Joint Commission to announce the publication of standard policy definitions for these very common clinical tools. While some hospitals will initially contend with meeting the new definitions, the long-lasting efficiency to the American healthcare system will be enormous.

They are welcome to start with my definitions, which are free. (Remember, you get what you pay for.) :)

On the Importance of Policy Mechanisms and Governance

Healthcare is going through change. Tremendous change.

Pay-for-performance, ACOs, EMRs, and a rapidly growing buffet table of regulatory bodies are forcing hospitals to adapt, and quickly. Hospitals and medical systems that can change quickly, adopt new standards, implement new tools, and provide low-cost, high-quality care will survive. Those that can't, won't.

So recently I've had several conversations with healthcare leaders who are looking for help making change. Some of the questions I've heard :

1. "What can I do to help us make change faster?"
2. "Why aren't our physicians (or committees) engaged?"
3. "What can I do to help improve communication?"
4. "What can I do to help standardize care in our organization?"
5. "What can I do to help us work together as a team?"
6. "What can I do to help us implement our Electronic Medical Record?"

Believe it or not, all of these questions are related by a thing called "hospital governance", and probably the most important tool for hospital governance is your policy manual.

Q : "Dirk, what is hospital governance? It sounds like a civics lesson, or something from Schoolhouse Rock."

Every organization, from Apple to IBM to small businesses to hospitals, have some form of governance - A set of tools to make decisions and take actions. Why? Someone has to make decisions, and then someone has to get work done. Unfortunately, organizing those people, who may have conflicting opinions, and getting them instead to work together can be challenging.

It's not enough to just have "talented staff". If your staff isn't working together the way you want them to, it might be a sign that you need to look at your governance structure.

So what is the biggest tool you have to govern yourself? Your policy manual. Unfortunately, the governance, policy manual, and policy mechanism of most hospitals is probably one of the least taught subjects in healthcare management.

Bear with me, I'm going to explain it in simple language. :)

Q : "So, Dirk, what's a policy? What's a procedure?"

A policy is a written goal of your organization. The procedure is the list of steps you take to achieve that goal. 

Good policy statements are short and sweet and clear. (A really good reference for this is Writing Effective Policies and Procedures : A Step-by-Step Resource for Clear Communication, by Nancy J. Campbell, 1998). Policy statements should not be paragraphs long - One or two sentences maximum. They should be clear and confident, e.g. :

     "All patients will get kosher meals..." or

      "All ED patients will get screened for influenza..." or

       "All pediatric patients will get weighed daily..." or 

        "All female patients over age 40 will be offered screening for..."

(You'll notice all of the above samples refer to subsets of patients, so they are all samples of clinical policies.) Good policy statements create clarity out of confusion, and help your staff understand your organizational goals.

The procedure, then, are the steps you take to achieve the goal stated in the policy, e.g. :

   "All pediatric patients will be weighed using the following procedure :

          1. Patient will stand on a digital scale

          2. Nurse will read digital readout on scale 

          3. Nurse will document the patient's weight in the patient's chart."

If you're not used to writing policies, it pays to invest in someone with training and experience. A good policy writer is worth their weight in gold. It's part art, part language, part human behavior, part communication, and part understanding workflows enough to write a good policy. Good policy writers can help create clarity out of confusion, and save your organization lots of money.

And you'll know if you have a good policy because someone on your front-line staff can read it, clearly understand it, and feel educated by the policy. 

When should you make a policy for something? Anytime your organization needs to standardize something.
      - Need everyone to get weighed on admission? Write a policy.
      - Need all patients over 50 to be given cancer screening? Write a policy.
      - Need all order sets to look the same? Write a policy.
      - Implementing a new tool that everyone will use the same way? Write a policy.

The danger, of course, in bad policies is that sometimes you can write too much. If you write too much, you can "paint yourself into a corner". This can be a problem when a regulatory body comes to look at your policies - In general, they look to make sure your policies reflect your practice. If you write too much, you can end up with policies that are too long, or that don't reflect your current practice, or that you have to keep amending/updating too frequently.

Again, this is why you should invest in someone trained in the art of policy writing, to help you write short, well-constructed, thoughtful, and clear policies. 

Q : "Can you give me a good teaching example of a policy and procedure?"

Sure. My favorite teaching example is this one :

POLICY : All patients will get a cupcake on admission.


PROCEDURE :

1. Kitchen staff will bake 100 cupcakes daily.
2. Couriers will bring cupcakes to floors.
3. Nurses will hand patients a cupcake when they are admitted.

What I like about this teaching example is it shows the thought that needs to go into a good procedure -

• It is a simple example which, while somewhat comical, people usually don't forget.
• It shows which staff will play which role (this is very helpful when figuring out who should review a policy before it is approved)
• "100 cupcakes" - It shows the thought that needs to go into writing an effective procedure. The trick : to include as much detail as is needed, and no more - (How many cupcakes will you need a day? How many admissions do you usually have?) 

This simple, well-written policy then helps directors budget for the time of their employees, and finance people to budget for the materials needed to make this policy work.

Q : "So what about the policy manual?"

The policy manual, then, is your total collection of policies. It should be treated like a sacred text. A good policy manual isn't torture - It's a source of education and communication across your organization. 

     - Have new staff you need to train? Use your policy manual!
     - Have old staff that you need to train? Use your policy manual!

     - Have directors who need to know "what's happening on the front"? Use your policy manual!
     - Have staff who need to know what the organization's rules/objectives are? Use your policy manual!

Q : "That seems pretty simple, is that it?"

Hardly.

Q : "What else do I need to know?"

Everything you do with those policies determines how your organization functions.

1. The way you organize your policies is important.

In a large organization, it's not enough to simply put all policies into one binder. You'll want to make a table of contents that guide your front-line staff to the policies they are looking for. Often, you'll want hospital-wide policies (apply to patients regardless of location), and department-specific policies (apply to patients in a specific location). And then you'll want to subdivide those chapters. (See my post about Policy Manuals Made Easy for an example of how you might divide your policy manual.)

2. The way you test your policies is important.

Before your policies are brought to a committee for approval, you'll want the policy writer to "test" them. That means, you'll want to know that the policy has been checked for accuracy, that the workflows are realistic, that the spelling has been checked, that the formatting is correct, that the proper stakeholders have been asked about the policy.

If you test your policies properly, before they are brought to a committee, there will be little discussion at your committee. Ever hear the statement, "Why are we discussing these details in the committee meeting?" The more time you spend in the "testing phase", the less discussion there will be in committee. I can't say enough about the importance of investing in testing, before a policy is brought to a committee for approval.

3. The way you approve your policies is important.

Depending on how you organize your policy manual, you will need a committee, or a group of committees, to approve your policies. A well-designed committee is small, efficient, and has a well-designed voting structure, run by a committee chairperson who understands basic rules of parliament and chairperson responsibilities. (For this, I recommend Robert's Rules of Order : Newly Revised - In Brief.)

If your committee has a well-designed charter (and voting structure), and is run by a chairperson who understands their responsibilities, the approval process will be efficient and the committee will make good decisions - ultimately they need to decide whether to approve, deny, or modify a policy.

And if you organize your committee structure properly, then subcommittees that struggle to approve a policy, or end up in a tie vote, should usually have a top-level committee that can discuss all of the policies that cause extensive discussion.

4. The way you publish your policies is important.

It's not enough to have well-written, approved policies in a binder in someone's desk or laptop. The policy manual has to be organized, comprehensive, and put in a place where everyone can access it. 

Every employee should know where it is, and should be introduced to it when they are hired.

5. The way you enforce and monitor your policies is important.

It's not enough to have well-written, approved policies in an organized, common policy manual. Managers need to enforce policies. Sure, during emergencies, there may be exceptions/emergencies where your front-line staff violate a policy, but when that happens, the employee should document the reason and managers/directors should ask "Why?". If someone is repeatedly violating a policy, it either means the policy is not appropriate/realistic, not properly designed, or the employee may need educating. (In my opinion, violating a policy should never be an automatic black mark against the employee - It should make the manager pause to reflect on the reason for the violation.)

It's also not enough to just schedule a re-review of policies every 2-3 years. Enforcement and monitoring is a continuous, ongoing job, which hopefully your managers are doing continuously. Those managers should be well-connected to your policy mechanism, so they can respond appropriately.

Finally, I will leave you with this Top-10 list of overheard comments which suggest your policy/governance mechanism may not be working the way you want it to :

1. "Why aren't our committees (or physicians) more engaged?"
2. "I don't know how to make a change around here" or "We can't change anything."
3. "Why didn't they tell us they were doing that?" (or "They have no idea what we're doing.")
4. "Who the heck passed that policy?" (or "That policy makes no sense.")
5. "Where is the policy manual?"
6. "I didn't know I was supposed to do that."
7. "Why do we have so many order sets?" (or policies, or protocols, or forms...)
8. "Our committee just decided against that, why are people still doing it?"
9. "Why aren't the owners updating their policies?" (or, "These policies are so old.")
10. "What can we do to standardize care?"

The good news is that organizing a policy manual and mechanism, and fixing your governance, can be a great experience that draws your entire staff together and rallies the troops. Feel free to leave your own stories about policy mechanism and governance!

Order Set Development and Preparing for the Downtimes

So as if order set development wasn't challenging enough, some people will ask :

"Dirk... So once you go electronic, you don't need paper anymore, right...?"

Well, here's the bad news. You will probably still need paper order sets.

"Huh...?"

Yep. It's true.

You will probably still need paper versions of all of your order sets, just in case your EMR / CPOE goes down.

I know it seems like a lot of work, but think about this :

1. After you develop electronic order sets, your doctors will come to rely on them.
2. The time they save using good order sets will increase their efficiency.
3. The good order sets you've built will help them standardize care.
4. This improved efficiency and improved standardization will, over time, allow you to make staffing changes.

The problem, however, will be : What happens when your EMR goes down?

1. Will your docs have order sets that accomplish the same goals as your electronic order sets?
2. Will your docs suddenly lose efficiency that they accomplished with those electronic order sets?
3. Will your docs be able to handle as many patients as they did with the electronic order sets?
4. If your docs rely on those order sets, and your computer is down... What paper order sets will they use?

So here's the message : It's good practice if you simultaneously develop matching paper and electronic order sets.

"But Dirk... it takes so much time to make an electronic order set... how do I make a matching paper order set?"

Some people, when confronted with this demand, will try this approach :

1. Have one team make the electronic order sets
2. Have some person, after the electronic order set is built, type out a matching paper order set.

This approach works, but I think a smoother approach is to develop an order set process that allows your informaticists to develop both paper and electronic order sets as part of the same process.

This gets us into a discussion about order set development.

After a hospital goes electronic, they generally try to use the same process they used before to make paper order sets. Unfortunately, because of the new demands an EMR brings :

1. Now - Will need both paper and electronic order sets developed at the same time
2. Now - Will need better engineering (e.g. order sets separated from protocols, etc.)
3. So... Will need informaticists to help engineer those changes
4. And... Will need Clinical IT Analysts to help build the work that the informaticists do

... Eventually, you start to realize : The old process doesn't meet the demands of an EMR.

So I generally recommend developing an order set change process.

The Order Set Change Process

Order sets are like any other clinical tool your hospital uses : You will need to define :

1. Who is the owner?
2. Who are the builders / project managers? (Generally, an Informaticist + Clinical IT Analyst)
3. What importance/priority does the order set/change have?
4. Who will assign this importance / triage changes?
5. Who will build the first draft? 
6. Who will test the new order set / changes?
7. Who will review the testing results?
8. What education plan (if any) will you need?
9. What companion documentation (if any) will you need?
10. What implementation plan (if any) will you need?
11. What accompanying clinical policy (if any) will you need?
12. What committee will "approve" your order set, after testing?
13. Who will implement the order set and the implementation plan?

So if you need to build both a paper and electronic order set, at the end of this process, here are my recommendations :

A. Develop an order set "Change Request Form". You will need this to help understand the expectations and understanding of your owner. Typical questions you might ask include :

1. Date of order set request?
2. Owner of order set? (I generally recommend this be a department director)
3. Builder/Informaticist assigned to order set?
4. Request :  (   ) new order set    (   ) delete order set     (   ) change order set
5. If requesting a change, what is the previous order set you wish to change? __________
6. What change are you requesting? (Please be specific) : ________________________
7. What companion documentation will you need? : _________________________
8. Will you need an education plan/curriculum for this change? : ____________________
9. Will you need an accompanying clinical policy to support this? : ___________________
10. Will you need a protocol to help support this order set? : __________________________
11. Will you need an implementation plan for this change? : _________________________
12. Priority of change : (1-5, 1=low, 5=high) : ___________
13. Expected date of completion : __________________

(Generally, at the bottom of this form, it's helpful to have signature lines that match the key, important parts of the process below, so you can help keep track of the process...)

B. Develop a process. You will then need a process where that change request form helps lead your process. A typical process might look like this : (I've highlighted the various characters, so you see how many people might be involved and the roles they play...)

1. Change Request Form is published throughout hospital (explain to docs/directors that all order set building/changes/deletions will be done according to this form)
2. Change Request Form is completed by owner, and brought to CMIO for triage.
3. CMIO and Clinical Analyst Project Manager review form and assign a priority and assign an informaticist and clinical analyst to work on the project.
4. Informaticist works with owner to define workflows.
5. Informaticist creates first paper draft of order set, using orders found in your electronic order library/EMR. (This helps make sure your paper version matches with your electronic order sets.)
6. Informaticist defines testing plan : What front-line clinical staff will be needed for testing?
7. Informaticist gives first paper draft to clinical analyst to build first electronic draft.
8. Informaticist helps prepare companion documentation (if needed)
9. Informaticist helps prepare clinical policy (if needed)
10. Informaticist helps prepare protocol (if needed)
11. Informaticist helps prepare education plan/curriculum (if needed)
12. Informaticist helps prepare monitoring plan (if needed)
13. Informaticist helps prepare implementation plan (if needed)
14. Informaticist and Owner execute testing plan - Using front-line staffmembers the owner makes sure show up for testing
15. CMIO and Informaticist review results of testing together, and review current versions of paper/electronic order sets, protocols, policies, companion documentation, education plan
16. If CMIO and Informaticist approve - Then proceed
17. CMIO puts paper/electronic order sets on agenda for Order Set Committee - Sends notification/drafts/links to committee members
18. Informaticist and Owner - Pass clinical policy through committee for approval
19. Informaticist and Owner - Pass documentation through committee for approval
20. Informaticist and Owner - Pass protocol through committee for approval
21. Order Set Committee meets to review both paper and electronic order sets
22. If Order Set Committee approves - Then proceed
23. CMIO sends notification of approval of final paper draft to printshop : Paper order set is coded and published (usually to a "red file cabinet" where you keep "order sets needed for electronic downtimes)
24. CMIO sends notification of approval of electronic version to clinical analyst  : Electronic order set is coded and published (by your analyst moving from test-->live, usually via your EMR)
25. Informaticist and Owner conduct implementation plan
26. Informaticist and Owner conduct monitoring plan (if needed)
27. Owner : Continuously monitors order set after use
28. (Restart at step 1 if needed) 

Yes, it's a lot of work. Seems monotonous and boring, but you will need to define a process for order set change management, or else you will end up with order sets that lack support, order sets nobody uses, order sets with no monitoring/involvement, and poor project management.

You'll notice that the Informaticist title up above appears in many steps in the process. This is why you'll want an informatics platform after you "go EMR". Clinical IT Analysts (sometimes mistakenly referred to as "programmers") actually play a much smaller role in implementation than most people think - They're mainly there during development, to make the technical changes and advise the informaticist on technical limitations. You'll also notice that order set owners, once you define this process, will become much more involved in the development, testing, implementation, and monitoring of their order sets.

Finally, you'll want a CMIO to help manage your informaticists, and help corral your doctors/directors into this new process.

And, if you engage in this sort of process, your informaticists will be building/approving simultaneous paper and electronic order sets :

1. ... so you can have an electronic order set that helps expedite the electronic ordering process (CPOE) for a common clinical scenario...
2. ... and at the same time, you'll have a matching paper order set that can be filed in an emergency file cabinet to be used during electronic downtimes.

Phew! As I said : With order sets, there are no shortcuts. 

This is part of the culture that EMRs bring. My advice : Prepare for change. :)

Would love to hear other people's stories - of how you developed a streamlined change management process for your order sets - I look forward to feedback! :)

Policy Manuals Made Easy

Hi folks. Happy new year! May 2011 be even better than 2010 was! :)

So I've been asked recently about where informatics policies should live, ideally, and I answered, "In the clinical policy manual."

That led to a follow-up question : "Dirk, what exactly is a clinical policy?"

This gets to the heart of a really interesting conversation about healthcare : The difference between a clinical policy and an administrative policy.

First, a word about policies in general.

Policies are probably one of the most misunderstood things in healthcare. Most doctors shudder when talk centers around, "We should make a policy for that" or "Do you know what the policy is for _______?".

A policy is a written, agreed-upon goal. (The "procedure", often attached to the same document, are the steps about how-to-get-to-that-goal.)

Policies, then, are your organization's written goals. That's why The Joint Commission asks about them, during inspections - They want to know how you organize, how you think, how you operate, etc. They also want to make sure the policies reflect the practices in your hospital.

Policies, if well-written, don't need to be painful. Policies help guide your staff behavior, they help communicate goals, and if they're well-written, they can also be used for training.

They also help protect your staff - Their activities are backed up by the organization's support for that behavior.

"Aha. So you were talking about maintaining policy manuals?"

That's right, I was. Thanks for reminding me. :)

So an interesting thing about healthcare, unlike private industries - We have two policy manuals, whereas most non-healthcare industries only have one.

"And what are those two policy manuals...?"

Interestingly, to maintain an average hospital, you need two general types of organizational control :

1. Clinical Policies - Those policies that refer to patients and patient care
2. Administrative Policies - Those policies that refer to employees and employee issues

Why do you need two? Well, an average healthcare organization is usually run by a Board of Trustees, who at some point made the decision, "We would like to run a hospital here."

To accomplish this, then, the Board usually needs :

1. A group of administrative people who are experts at running the hospital - Keeping it organized, hiring people, making sure supplies show up, paying the bills, setting up the budget, running the place, sending out bills to insurers, etc.
2. A group of clinical people who are experts at delivering patient care - Performing surgery, seeing patients, taking vitals, giving drugs, managing ventilators, etc.

And that's why most hospitals typically have two wings of government :

1. The Administrative Branch
2. The Clinical Branch

... and the policy manuals that are used to help run these two branches of government are :

1. The Administrative Policy Manual
2. The Clinical Policy Manual

"I see... So what else do I need to know?"

Well, to run an average hospital, then, you need to have both clinical and administrative policies that help guide your daily activities. The conflicts that sometimes arise, between these two branches of internal government, are sometimes very complicated - And, as a result, not every situation calls for a clear administrative or clinical policy.

"So how do I recognize an administrative policy from a clinical policy?"

An administrative policy statement usually refers to employees or employee issues, so they typically start with something like this :

"All employees at Acme Healthcare will..." or

"All physicians at Acme Healthcare will..." or

"All nurses at Acme Healthcare will..." or

"All ED staff at Acme Healthcare will..."

The collection of these administrative policies is typically kept in an administrative policy manual.

A clinical policy statement usually refers to patients or patient care issues, so they typically start with something like this :

"All patients at Acme Hospital will..." or

"All pediatric patients at Acme Hospital will..." or

"All ED patients at Acme Hospital will..." or

"All terminally ill patients at Acme Hospital will..."

The collection of these clinical policies is typically kept in a clinical policy manual.

"Aha. So how do you organize these policies, then?"

Every hospital has a slightly different way of organizing them, but I recommend a very simple system of organizing them :

1. Administrative Policy Manual

     a. General Hospital-Wide Administrative Policies

          - Human Resources

          - Safety

          - Information Management / Medical Records

          - Quality Management

          - (Other organizational administrative policies)

     b. Department-specific Administrative Policies

          - ED

          - Medicine

          - Surgery

          - OB/GYN

          - Pediatrics

          - (etc..)

2. Clinical Policy Manual

      a. General Hospital-Wide Clinical Policies

           - General Clinical Policies 

           - Quality Management

           - Nursing

           - Medical Records / Informatics

           - Laboratory

           - Radiology

           - Infection Control

           - Dietary

     b. Department-specific Clinical Policies

          - Medicine

          - Surgery / OR

          - OB/GYN

          - Pediatrics

          - ICU

          - (etc. etc.)

Again, as I said, every hospital does this a little differently, to address their different needs, but the general theme is that they are all generally clinical or administrative policies, and they generally either apply throughout the hospital or in a specific department or physical area.

"Dirk... That sounds like a lot of work, then!"

It is a lot of work. If every policy has to be approved by a person or committee, there's a lot of work that goes into maintaining these policy manuals. Many hospitals struggle with doing this efficiently.

The good news is that it doesn't have to be torture. By delegating each branch of policies to the right person/committee, you can divide up the work efficiently, for example :

1. Clinical Policies

      a. Hospital-wide Clinical Policies

           - General Clinical Policies = Approved by Medical Executive Committee

           - Nursing Policies = Approved by Nursing Committee

           - Medical Records / Informatics = Approved by Med Rec / Informatics committee

           - Pharmacy Policies = Approved by P&T Committee

           - Infection Control Policies = Approved by Infection Control Committee

      b. Department-specific Clinical Policies

           - Medicine - Approved by Medicine Committee

           - Surgery / OR - Approved by OR/Surgery Committee

           - ICU = Approved by Critical Care Committee

           - Pediatrics = Approved by Pediatric Committee

You'll notice the theme : Every branch of clinical policies will either need a committee or a person, delegated to maintain and approve that particular chapter of the policy manual.

And you'll notice how much work it takes to maintain all of this. Every time a drug gets recalled, every time the government creates new billing standards, policies have to be adjusted and re-approved.

The good news, if you do this well, is that you can use the policy manual as an education tool :

- For new staff who are orienting to your hospital

- For existing staff who would like to quickly find out daily operations

Finally, an important part about maintaining all of these separate chapters is that even if you delegate the maintenance of these chapters to different committees, it's imperative that you publish all of these policies in the same place. (That means, that all "active policies" are kept in one common place, where everyone can look at them.) By keeping the entire manual (all chapters) in one place, it :

1. Helps avoid policy conflicts between different departments, and
2. Helps make the policy manual a tool of organization and education for your staff.

Again, as I've said before, my advice is free and you get what you pay for. Every hospital does this a little differently, but I hope I've communicated the major themes. Would love to hear your stories and thoughts about best ways to organize a clinical and administrative policy manual!

Find any document in your hospital in five clicks?

It's December. The squirrels have gathered their nuts. The leaves have fallen. People are having their holiday parties. It's a time for reflection, as we anticipate the new year 2011 that lies ahead. Healthcare is changing faster than ever before, and those who want to survive, need to keep up.

I've spoken in previous blog posts about the tools we commonly use to deliver care in modern healthcare. So as I've been thinking about how to streamline organizational efficiency in healthcare, one of the major challenges most hospitals face is : How do we manage all of this information?

Some people will immediately look to IT for solutions, since we think of information as living inside a computer, but IT can only build a system as organized as you ask them to build. The problem is : If you had chaos before, making things electronic will only perpetutate the confusion.

(I've spoken to plenty of healthcare informatics types who complain about not being able to navigate their web sites, shared electronic folders that never get updated, and not having "intuitive" organization of their information.)

I find the comment, "We don't have intuitive organization of our information" particularly interesting. Everyone seems to have a different idea of what is intuitive.

All of this speaks to the need for standardization in healthcare, and education to support those standards. (Nobody teaches this stuff in medical school, nursing school, or pharmacy school.)

So I hope I've attracted your attention with the title of this blog. My proposal : We develop a standard "document tree" that can be used to organize virtually all of your hospital's information. (Except emails, of course, which generally are private and not shared.)

The Healthcare Informational Tree

So I thought about all of the common tools we use in healthcare (the CMIO's Checklist and the Informatics Toolbelt), and sorted them first by function and then by division (Clinical versus Administrative) - And this is what I got as a final list :

1. Telephone Numbers - Tools to contact a person
2. Emails, Screen Savers, and Posters - Tools to help send a short message
3. Schedules - Tools to show who is responsible at what date/time
4. Policies and Procedures - Tools to learn organizational standards and how to achieve them
5. Guidelines - Tools to help educate and guide staff towards a desirable outcome
6. Documentation - Tools to record and transmit information
7. Orders - Tools to document and transmit instructions to deliver care
8. Order sets - Tools to standardize and expedite the ordering process for a common clinical scenario
9. Clinical Protocols - Tools to standardize and automate a clinical process
10. Clinical Pathways - Tools to standardize care for a diagnosis throughout a hospitalization
11. Education Modules - Tools to help educate patients/staff
12. Templates - Tools to help make a document
13. Wikis - Tools to organize information / links for a department
14. Committee Charters - Tools to assign committee duties and responsibilities
15. Committee Minutes - Tools to record committee activities
16. Glossary of Terms - Tool used to learn definitions for common organizational terms

I believe that by using the above directory/tree hierarchy, you could arrange your tools on your intranet in a way that you can essentially find any document in your hospital in five clicks - Each link, from this main page, then divides up into clinical and administrative divisions, e.g. :

• Clinical Templates = e.g. Admission H&P template, Procedure Note template, Transfer Summary template, etc.
• Administrative Templates = e.g. Policy and Procedure template, employee evaluation template, etc. 

or

• Clinical Documentation = e.g. Admission H&P, Procedure Note, Transfer Summary, Vitals Flowsheet
• Administrative Documentation = e.g. Employee Evaluation Form, Room Change Form, Maintenance Request Form

or

• Clinical Policies = e.g. Pharmacy Policies, Infection Control Policies, Nursing Care Policies, etc.
• Administrative Policies = e.g. Human Resources Policies, Safety Policies, etc.

The interesting thing about making such a tree is it shows you, pretty quickly, how much work you are actually doing in your hospital, how much it actually takes to run a hospital, and why you need people to worry about all of these tools.

It also can help you find your work products much quicker, and it interfaces nicely with the tools that you need to make a change in the clinical setting.

Adopting such a tree is not a small project, but it sure can tidy up your intranet homepage. It also helps reinforce informatics education by making almost everyone in your organization review the basic tools you use, and what they do, every time they look for something. By having centralized publishing, this also helps keep your intranet a "high-value" site that people will use to find things.

As someone who wants to see American healthcare be the best that it can be, I think it's an admirable goal. Those of us working to organize Health2.0 should be keeping this tree in mind as we develop our healthcare informatics policies.

Remember, my advice is free, and you get what you pay for. Your mileage may vary. :)

Would love to hear comments about potential additions/changes you would make to the tree at your organization! :)

What is Medicine Reconciliation, anyway?

So recently I've been hearing and reading a lot about medicine reconciliation.

Medicine reconciliation is the safety practice that, it seems, The Joint Commission has recently announced they will set new expectations for.

A friend of mine, who went to an IHI conference last year, told me that on a wall full of posters of "problem subjects", the "Med Reconciliation poster" seemed to have the most hospitals reporting challenges.

So what is this Med Reconciliation thing, anyway?

• Is it a mythical creature that people see, but nobody ever really gets a picture of?
• Is it something that inspires poets and artists, because it's so intangible?
• Is it something that we can even achieve?

Most practicing physicians learned in medical school that it's "good practice to rip up and re-write all the orders when a patient comes out of the OR". Most practicing physicians are also used to documenting the patient's home medication list in an admission H&P. The interesting thing : These are both different facets of the same med reconciliation picture.

So then, I think one of the biggest challenges in implementing "Med Reconciliation" is that it's so hard to nail down. What is it, exactly? Who does it? And how? 

So I thought I'd share some answers.

WHAT IS MED RECONCILIATION?

I. THE PREMISE :
 First, the premise is simple : It's all about safety.

Med reconciliation is built on the basic premise that a physician and a patient work best together, when they're with eachother. For the purposes of this discussion, I've lovingly decided to call the "place where they work with eachother" the "Patient Care Cubicle" (instead of the industry term, "Level of Care" which is a little confusing.).

The process is then pretty simple. To perform med reconciliation, a physician needs two separate documents :

1. The 'home medication list', to know what the patient is 'usually on'.
2. The 'active medication list', to know what the patient is 'currently on' while sitting in this "patient care cubicle".

And the steps for doing med reconciliation? A doctor should basically follow these four steps :

1. Look at the Patient
2. Look at the HomeMedList
3. Look at the CurrentMedList
4. Make a new CurrentMedList!

This allows a physician can make the decision : What meds does the patient need to be on right now.

So remember, the recipe for med reconciliation needs these four ingredients :

   MED RECONCILIATION = [ Patient ] + [ Physician ] + [ HomeMedList ] + [ CurrentMedList ]

(While they are connected, remember - Med reconciliation is NOT the process of collecting the home med list - But you will need to collect the home med list before a doc can do med reconciliation.)

So... when does a physician actually do these four steps of "med reconciliation"? Optimally, it happens at two times :

1. When the patient appears in your cubicle (in hospital terms this is known as a "change in level of care")
2. When the patient has had some significant event (like delivering a baby, a code blue, a surgery, etc.)

So far, so good. Now comes the implementation challenges.



B. THE BASIC IMPLEMENTATION

The first thing you might do to map out the implementation of med reconciliation, is to make a general map of all of the "patient care cubicles" your patient might pass through, when he/she goes through your hospital. Typically, this map will start with the outpatient cubicle, and end with the outpatient cubicle. (On discharge, then, you need to do med reconciliation one last time to define the "new home med list", aka the "discharge medication list").

So if each "cubicle" has the patient and a physician :

1. The physician covering the "outpatient cubicle" is the primary care physician.
2. The physicians covering the other cubicles are the ones you assign.

And so if you need two lists - The home med list, and the current med list - To perform med reconciliation, you can see by the above slide that the first challenge will be getting the home med list available in your ED.

This brings us to some challenges with med reconciliation...



C. THE FOUR BIG CHALLENGES

The first challenge is just getting the home med list in your ED. How long does it take to actually assemble the list of home medications? (Remember : THIS IS NOT MED RECONCILIATION YET - Collecting this list is probably the thing most commonly confused with the term "med reconciliation".)

I did an informal study of this, while working clinically last year, and found that my median time for most adult medical inpatients was about 20 minutes. About 2/3 of my population was less than this, but about 1/3 of my patients were more than this, and there were some significant outliers - some patients took up to 45 minutes or more. (While slightly tongue-in-cheek, I called the standard I used the "mother standard", figuring I would work to achieve the same accuracy I would expect for my own mother.)

The reason it can take some time to assemble is this : There are up to seven data sources a person can use to assemble the home medication list. They include :

1. The patient - Who usually knows their home med list... but not always.
2. The family - Who is often helpful at establishing an accurate med list, but not always
3. The PCP - Who is usually accurate, as long as the office is open and they know what the specialist might be prescribing, so...
4. The specialist - Who sometimes needs to be contacted for clarification about new specialty medications
5. The outpatient pharmacist - Can be helpful to get a broad view, assuming the pharmacy is open and the patient doesn't use a mail-order pharmacy
6. The previous chart - Can also be helpful, assuming the last visit wasn't too long ago
7. The "insurance-based electronic prescription database", available at some hospitals - Which also still sometimes takes time to sort through, and you have to make certain assumptions...

So if the first step is to assemble this list in the ED, then the first challenge is to figure out who will assemble this list, and how?

Curiously, if you examine med reconciliation needs in the ED department, it usually falls along these steps :

1. Triage desk Officer : Generally drug classes are most important, not actual drug names. (E.g. a triage officer may consider bringing someone in if they are on blood thinners, or antibiotics.)
2. ED physicians : Generally drug names are most important, sometimes doses. Most ED visits are short, so there has not traditionally been much focus on doing med reconciliation in the ED. Of course, if we expect ED physicians to perform med reconciliation, they will need more information. (Some patients do miss medication doses while waiting for care in the ED.)
3. Inpatient Physicians : Here is where the drug, dose, route, frequency, indication, and last dose are most important, because the patient staying in-house will need to continue the right medications at the right times.

Because of these varying needs, at these different levels, it's sometimes hard to figure out who's responsible for how much of the puzzle.

The second challenge, assuming you can get the home med list assembled in the ED, is figuring out : Which physicians will be responsible for actually doing med reconciliation in each cubicle?

While it's tempting to answer :

1. ED - Would be performed by ED physicians, 24/7
2. Floor - Would be performed by hospitalist physicians, 24/7
3. ICU - Would be performed by intensive care physicians, 24/7
4. Etc...

...the PreOP setting/OR/PACU usually presents some unique challenges (challenge #3)

The challenge for many ORs/PACUs is this : Operating room schedules are tight. Hospitals count on maximum efficiency in an operating room. Even small delays can be magnified into cancelled procedures if everything doesn't run like clockwork. Also : Surgeons and anesthesiologists spend a good part of their day in procedures that simply can't be interrupted. Briefly pulling a hospitalist out of a family meeting to "do med reconciliation" will have a very different cost than briefly pulling a surgeon / anesthesiologist out of a surgery.

To accommodate with these demands, many anesthesiologists focus mainly on anesthesia meds, and many surgeons write post-operative orders in the PACU. If the patient goes up to the floor, after the PACU, then the nurses depend on the post-op orders written by the surgeons in the PACU. Unless you create a cubicle where the PACU has the same level of care as the floor, you might have to do med reconciliation again after the patient reaches the floor.

Figuring out this workflow can be very challenging. It's why my friend, going to the IHI conference last year, saw Med Reconciliation as one of the 'top challenges' hospitals face.

The fourth, and final challenge, is deciding on the "triggers" you will use for med reconciliation. As described above, there are typically two things that should trigger a physician to actually perform med reconciliation :

1. Patient arrives in your patient care cubicle (aka "Change in level of care") - This is usually pretty easy to enforce electronically.
2. Patient has a significant change in status (e.g. delivery, surgery, code blue) - This can only be enforced by a policy/clinical practice.

So you will need to decide on these two triggers, knowing that

1. For your EMR to trigger med reconciliation electronically, you will need to organize your levels of care and their relationship to your patient locations.
2. For your staff to trigger med reconciliation during a significant patient event, you will need good policy design and education.

D. THE NEXT STEPS / SOLUTIONS

Fear not, my reader! This may seem daunting, but the problem can be solved! Many hospitals have started down this pathway already, and many more will continue as The Joint Commission and other regulatory bodies reinforce med reconciliation practices.

To help you, I've offered the following recommendations and steps you can take to advance the discussion in your own hospital.

1. Define who is responsible for collecting the home med list in the ED
2. Define what home medication information they will collect, and how? (It's challenging to figure out how many of the seven potential data sources to use, but until our whole country is wired together electronically, your organization will need to decide this.)
3. Define where this home med list will be kept, once assembled, so that every doctor in the "chain of cubicles" will be able to access it and use it to perform and document "med reconciliation".
4. Define your "patient care cubicles", where your EMR can help trigger the med reconciliation process.
5. Define your policy that will help educate physicians about clinical scenarios in which you expect med reconciliation to be performed (e.g. delivery, code blue, surgery, etc.)
6. Define which physician's will be responsible for the med reconciliation process in each cubicle, 24/7.

Regarding the unique challenges that most Operating Rooms/PACUs present, this is a very common challenge, but I'll present the following possible scenarios I came up with :

1. Your hospital might consider asking the surgeons to perform med reconciliation after the patient arrives back up on the floor. (This may cost your hospital in OR time/efficiency.)
2. Your hospital might consider transferring all post-op patients to your hospitalist group, to allow the hospitalists to perform med reconciliation on the floor. (This may cost your hospital by needing more hospitalists to care for these patients.)
3. Your hospital might consider hiring a Physician's Assistant (PA) or Nurse Practitioner (NP) to assist the surgeons with the med reconciliation process. (This may also cost money, but I believe in most settings this would be more affordable than option #1 or  #2 above.)

Enjoy - I hope this discussion has been helpful. A good sample policy to support med reconciliation is available here from the University of Wisconsin Hospital and Clinics.  Again, I'm eager for any feedback folks have. Feel free to leave your own stories about tackling med reconciliation! :)

Converting paper order sets to electronic

If you're reading this, I hope you're the person in your institution trying to "convert the paper order sets to electronic ones".

Don't worry - you're perfectly normal. The job is usually a lot harder than it looks. And no, you're not the only one who hears, "Why can't you just take the paper order sets and put them on the screen?"

(Most people think it's simple, until they actually start to dissect the order sets.)

First, let's start with some of the challenges of paper order sets :

1. Paper order sets generally keep multiplying - Let's say you decide to fix the paper order sets, and so you need to take the old versions "off the shelves". Beware - People tend to make copies of paper order sets. So the old ones can turn up weeks and months later.
2. Paper order sets are often engineered differently - In the electronic (CPOE) world, orders are very concrete. You may have specific safety features put into your electronic PCA (Patient-Controlled Anesthesia) order. How will you put those safety features into your paper order set? You may also have hidden "protocols" in your paper order sets. What will you do with those protocol (conditional) orders? 
3. Paper order sets are sometimes ignored, after a hospital "goes electronic" - If you ignore your paper order sets, what will your hospital use during electronic downtimes? Can you afford not to have paper backup order sets, if your OR/ED are busy?

Believe it or not, how you address these paper-order-set problems will be vitally important in your long-term electronic success. Ignore the paper order sets, and you will miss an opportunity to really set up a robust electronic platform.

Let's look at each of these issues in a little more detail :

1. The "Multiplying paper order sets" -

This is a phenomenon many organizations struggle with. The solution : Centralize all of your order sets on one common electronic web site, and publish them as non-editable .PDF files. Create a clinical policy where "If it's not on this site, it's not an acceptable order set".  It will take you a while to get the site together, and organize all of your paper order sets there, but in the end, you will have a way of controlling the paper order sets in use. 

2. The "Engineering differences" between paper and electronic order sets

Some organizations, on going electronic, focus on developing electronic order sets, while the paper order sets continue to be produced in the way they "always have been built". If you have two separate processes (an electronic and a paper process), the problem is that you will start to have significant engineering differences between the two. 

If you have different paper and electronic order sets, you will then encounter :

• Paper order sets that don't meet the engineering standards needed for order entry in your EMR, so they will be very hard to "send-to-pharmacy-so-someone-else-can-do-the-order-entry"...
• Paper order sets that don't match the electronic order sets
• Two cultures : Docs who use electronic order sets, and docs who use paper order sets. (If your organization does a "flip-the-switch" approach to EMR/CPOE, then this won't apply to you. If you do a "gradual conversion", then this will apply to you.)

The way you fix this, of course, is to develop simultaneous paper and electronic order sets. Set up your informatics platform, update your policy on order set development (to include paper and electronic order sets), and ask your informaticists to develop the paper and electronic order sets simultaneously. Have them tested by the same people, and approved by the same committee. This will ensure that they match, and even if you are a "100% CPOE" organization, you will still appreciate having matching paper order sets during electronic downtimes.

Remember, the solution isn't to make electronic orders that mirror your bad paper processes. Make good, solid, and safe electronic orders, and then use those in your updated paper order sets.

A final tip : Embedded "protocol" (conditional) orders generally need to get pulled out of the paper order sets, before you can "make them electronic" - and you will need to decide what to do with those : A. publish them as new protocols, or B. throw them out. This will take work and can be politically challenging. 

3. The "Ignored Paper Order Sets"

Some organizations, on going electronic, ignore the paper order sets, thinking, "We don't need them anymore, right?". My advice : Don't ignore them. Not only will you need to figure out what your pharmacy will do if they end up getting faxed paper orders, but you will still need them for computer downtimes.

If all of this sounds complicated, and it sounds like a lot of work, you're right - It is. This is why order sets are the political and organizational challenge that they are. A good informaticist can help sort out the issues and put a plan and process into place for your organization, where it doesn't have to be too painful. Unfortunately, because healthcare doesn't have standards in clinical processes, every organization handles this conversion differently, and as a result, order sets are notoriously hard to standardize. (Think of them as a "custom-fitted suit".)

One last tip : Beware the "quick fix" - There are consultants who will "easily and quickly convert your paper order sets to electronic ones". The way they usually do this is by taking the paper orders, no matter how they are engineered, and simply build new electronic orders that match them. In the short term, this may appear to work, but in the long term, it may leave the nurses with orders which are unclear (and may create extra pages to doctors to clarify), since some paper orders are not as well-defined as their electronic counterparts. You may also miss out on the opportunity to streamline your clinical processes, and miss out on the time and cost savings that an EMR can really bring. My recommendation : Build the new paper order sets to match the engineering standards of your electronic order sets - Not the other way around. 

As always, my advice with order sets : There are no quick fixes. Hire a good informaticist to help you with this. :)

Hey, by the way, I'm open for questions - If anyone has any EMR conversion or informatics questions that you'd like to chat about, feel free to leave a comment here or email me. I'll try to devote my next posts to reader questions! So send me stories, questions, or whatever else you'd like to discuss in upcoming posts - I look forward to hearing from folks! :)