Weaving the DNA of #Healthcare. Learn about front-line applied clinical informatics, clinical workflow design, and EMR implementation with an experienced CMIO. Open discussion is encouraged, education is a priority. All opinions are strictly my own.
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 :
Order sets - Contain orders that are activated/modified/deactivated by a physician.
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.) :)
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 :
"What can I do to help standardize care in our organization?"
"What can I do to help us work together as a team?"
"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.
"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.
Kitchen staff will bake 100 cupcakes daily.
Couriers will bring cupcakes to floors.
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?"
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 :
"Why aren't our committees (or physicians) more engaged?"
"I don't know how to make a change around here" or "We can't change anything."
"Why didn't they tell us they were doing that?" (or "They have no idea what we're doing.")
"Who the heck passed that policy?" (or "That policy makes no sense.")
"Where is the policy manual?"
"I didn't know I was supposed to do that."
"Why do we have so many order sets?" (or policies, or protocols, or forms...)
"Our committee just decided against that, why are people still doing it?"
"Why aren't the owners updating their policies?" (or, "These policies are so old.")
"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!
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.
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 :
After you develop electronic order sets, your doctors will come to rely on them.
The time they save using good order sets will increase their efficiency.
The good order sets you've built will help them standardize care.
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?
Will your docs have order sets that accomplish the same goals as your electronic order sets?
Will your docs suddenly lose efficiency that they accomplished with those electronic order sets?
Will your docs be able to handle as many patients as they did with the electronic order sets?
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 :
Have one team make the electronic order sets
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 :
Now - Will need both paper and electronic order sets developed at the same time
Now - Will need better engineering (e.g. order sets separated from protocols, etc.)
So... Will need informaticists to help engineer those changes
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 :
Who is the owner?
Who are the builders / project managers? (Generally, an Informaticist + Clinical IT Analyst)
What importance/priority does the order set/change have?
Who will assign this importance / triage changes?
Who will build the first draft?
Who will test the new order set / changes?
Who will review the testing results?
What education plan (if any) will you need?
What companion documentation (if any) will you need?
What implementation plan (if any) will you need?
What accompanying clinical policy (if any) will you need?
What committee will "approve" your order set, after testing?
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 :
Date of order set request?
Owner of order set? (I generally recommend this be a department director)
Builder/Informaticist assigned to order set?
Request : ( ) new order set ( ) delete order set ( ) change order set
If requesting a change, what is the previous order set you wish to change? __________
What change are you requesting? (Please be specific) : ________________________
What companion documentation will you need? : _________________________
Will you need an education plan/curriculum for this change? : ____________________
Will you need an accompanying clinical policy to support this? : ___________________
Will you need a protocol to help support this order set? : __________________________
Will you need an implementation plan for this change? : _________________________
Priority of change : (1-5, 1=low, 5=high) : ___________
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...)
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)
Change Request Form is completed by owner, and brought to CMIO for triage.
CMIO and Clinical Analyst Project Manager review form and assign a priority and assign an informaticistandclinical analyst to work on the project.
Informaticist works with owner to define workflows.
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.)
Informaticist defines testing plan : What front-line clinical staff will be needed for testing?
Informaticist gives first paper draft to clinical analyst to build first electronic draft.
Informaticist helps prepare monitoring plan (if needed)
Informaticist helps prepare implementation plan (if needed)
Informaticist and Owner execute testing plan - Using front-line staffmembers the owner makes sure show up for testing
CMIO and Informaticist review results of testing together, and review current versions of paper/electronic order sets, protocols, policies, companion documentation, education plan
If CMIO and Informaticist approve - Then proceed
CMIO puts paper/electronic order sets on agenda for Order Set Committee - Sends notification/drafts/links to committee members
Informaticist and Owner - Pass clinical policy through committee for approval
Informaticist and Owner - Pass documentation through committee for approval
Informaticist and Owner - Pass protocol through committee for approval
Order Set Committee meets to review both paper and electronic order sets
If Order Set Committee approves - Then proceed
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)
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)
Informaticist and Owner conduct implementation plan
Informaticist and Owner conduct monitoring plan (if needed)
Owner : Continuously monitors order set after use
(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 :
... so you can have an electronic order set that helps expedite the electronic ordering process (CPOE) for a common clinical scenario...
... 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! :)
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 :
Clinical Policies - Those policies that refer to patients and patient care
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 :
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.
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 :
The Administrative Branch
The Clinical Branch
... and the policy manuals that are used to help run these two branches of government are :
The Administrative Policy Manual
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
- Information Management / Medical Records
- Quality Management
- (Other organizational administrative policies)
b. Department-specific Administrative Policies
2. Clinical Policy Manual
a. General Hospital-Wide Clinical Policies
- General Clinical Policies
- Quality Management
- Medical Records / Informatics
- Infection Control
b. Department-specific Clinical Policies
- Surgery / OR
- (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 :
Helps avoid policy conflicts between different departments, and
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!