Sunday, June 29, 2014

My Open Letter to the New Physician Leader

So I've been in my current position for almost seven years now. I've learned a lot during that time, and I always enjoy sharing my lessons with other people, so maybe they won't have to spend as much time learning them as I did. So in the spirit of education, and with love and fellowship for other physician leaders, I share this blog post:

MY OPEN LETTER TO THE NEW PHYSICIAN LEADER 

To the New Physician Leader,

Welcome! You're a board-certified physician who has been honored by being asked to serve some sort of leadership position in healthcare, generally either a committee chair, department chief, or physician executive. Given all of the reform and change going on, we need good physician leadership in healthcare! We need you to bring a physician's voice to the discussion, and your hours spent in the ED, OR, ICU, floors, or clinic, will help keep you honest and patient-focused. Your experience will help answer detailed questions about how to deliver great patient care. Your clinical hours are being cut with the expectation that you will step into this new role, help coordinate with other physicians, help shape the future of healthcare, and make it great.

Unfortunately, there's no great training course for this new role. Some of you got voted into your positions, whether you wanted it or not. Some of you demonstrated your skills at many long committee meetings, and eventually earned a reputation as a physician leader. And some of you obtained MBAs, MPHs, or other advanced degrees which helped to get you started in your new role.

But I'm writing to share with you some of the lessons that I've learned in my seven years as an eternally questioning physician leader, in the hope that you will use them in any way you see fit - Hopefully, to prevent you from learning the lessons as slowly as I did.

So with that, I humbly offer you these ten lessons that either I've learned myself, or that were shared with me from other physician leaders :
  1. Don't think being a doctor prepares you for this leadership role. Medical school teaches us a lot about anatomy, physiology, pathology, and histology. Residency teaches us a lot about medicine, surgery, OB-GYN, pediatrics. Fellowship teaches us a lot about pulmonary/critical care, neurosurgery, and cardiology. Experience may teach us how to do our job, or lead a clinical team to a successful surgery. That education and experience will serve you well in this new role, but there is still much to learn. Leading a clinical team through a surgery is very different than leading a whole department or a clinical service. Always be humble and thankful for the people who teach you new things. In my opinion, as physicians, we should always strive to be both teachers and students for the rest of our lives.
  2. Set high standards for yourself. You have one shot at this. Don't just be "good enough." Be "good enough for your children." Attention to detail can be the difference between success and failure, and we need you to be successful in your new role. Don't just aim to succeed - Distinguish yourself by aiming to succeed and wow. Don't just try to meet legal standards, try to meet ethical standards.
  3. Learn some basic parliamentary procedure. Buy yourself a copy of "Roberts' Rules of Order" and read it. Keep your copy in your new office. Knowing how to run a good meeting is a critical skill that not everyone has. When the opportunity arises, being able to correctly discuss the difference between a primary motion and a secondary motion is very impressive. You will also need to know this if you have to make any big changes, which will invariably involve politics and governance.
  4. Know how to write a really good committee charter, meeting agenda, and minutes. These tools are so essential to success, and still many physician leaders don't pay much attention to them. If you really care about these documents, you will be empowered by knowing how to run really good meetings where people show up and things get done.
  5. Control your documents, don't let them control you. Simply put, documentation matters. First, make sure you read your organizational chart, bylaws, rules and regulations, and policies (at least once), and make sure you understand what they all do. Physician leaders sometimes fail because they don't know or understand their governing and operational documents. Next, make sure you know how to develop a really good document - Starting from your idea, to your regulatory/policy/literature search, to your stakeholder list, to your well-designed template, to your first DRAFT, to your stakeholder review, to your final draft, to your FINAL document approval, to your document publication and monitoring - Every step is essential to making a good document. It doesn't matter how good and well-planned your idea is - If it's not properly developed and documented, then it's likely to fail. Finally, keep all of your computer documents somewhere where other people can find them. If you keep all of your tools on your local C: drive, or your email, then nobody else can see them, read them, or collaborate on them. And if you get sick or leave - They may be lost forever! A much better place to keep them is an internal, secure, shared network drive that many people in your organization have access to - It facilitates collaboration, and someone else can find things if you're sick!
  6. "Workflow" is everything. While this term is often used when trying to implement an EMR, everyone should know what it means and why it's important. Workflow is actually deceptively simple. It's a procedure. The success (or failure) of your projects and departments will depend on having good, clear, well-designed, cost-effective workflows that build best-practices into your daily routines. To document your current and future workflows, some people try to make elaborate Visio diagrams or flowcharts, but it doesn't need to be that complex, and sometimes the complex diagrams can leave out important details. You may still need expert help when trying to fix workflows, but as a start, try studying food recipes to see how easy it can be to write good procedures. By design, food recipes/procedures/workflows are generally very 'lean' (in process, not necessarily nutrition - Sorry, no pun intended!) You may still need expert help when trying to fix workflows, but you can start writing a good procedure/workflow, line-by-line, using the general format [ WHO ] will [ WHAT ] [ how ] [ when ] [ where ] [ why ], where the bold parts are mandatory and the italic parts are optional (and only used when needed.) Once you have your current state workflows documented in this manner, you'll quickly see where it can be streamlined to develop your future state.
  7. Don't just make the future good, make it excellent. It's easy to get lost in trying to preserve the past. Sure, there are some things you'll want to keep (like good patient care, compassion, and continuity), but some of healthcare was broken. Make sure you're not trying to preserve the stuff that was broken. (This is especially important when trying to go electronic - You do not want to build bad workflows into your new electronic system!) Remember - Doctors will still be doctors after healthcare reform. We may look a little different, work a little different, and even get paid a little different, but patients will still need us to help them. Plan to make the future excellent for both patients and caregivers.
  8. Finance matters. Through medical school, residency, and fellowship, most doctors don't pay much attention to financial issues (other than student debt!), but at the end of the day, clinical decisions need to make financial sense, and many hospitals close because of insufficient funds. Every penny counts. To make sure everything you do has value, and your projects are well-planned and financially sound, always include someone from finance/accounting early in your clinical discussions. Doctors have as much to learn from finance as finance has to learn from doctors. 
  9. Prepare for shared governance. Let's face it - In the old days, doctors 'ruled' the hospital, while nurses actually kept it alive and functioning. That model doesn't work anymore - You were hired because the nurses can't do it alone. Some people mourn the passing of those days. Personally, I don't. In the future, doctors, nurses, pharmacists, quality, regulatory, legal, and financial people will work together to break down silos, answer questions and collaborate on decisions. I love working collaboratively because I learn so much from these other team members. Working together, we reduce costs, avoid workflow problems, and make better decisions. 
  10. Always let the patient guide your compass to True North. I was once given this advice by another physician leader when I asked him, "How do you always know what to do?". He basically told me, "As long as you always think about the right thing for the patient, you'll always know what to do." I've spent seven years validating his advice, and I can say that so far it has served me very well.
We desperately need you to help shape the future of healthcare, and shepherd other physicians and advanced practice clinicians (PAs, NPs, etc.) through this transition process. To help our patients, we are counting on you to be both happy and successful in your new position! Good luck, share your lessons with other people, and always remember why you applied to medical school in the first place - to help people.

Humbly submitted,

- Dirk
(fellow student, teacher, and eternally questioning physician leader)


Remember - This blog is for educational purposes only, so I always welcome opinions and feedback! Do you have any lessons you would share for a new physician leader? Leave them in the comments below!

Sunday, October 27, 2013

The "Poor Man's Document Sharing" Strategy

Hi - Sorry it's been a while since my last post. As most of you in #HealthIT know, Meaningful Use Stage 2 (MU2), Health Information Exchange (HIE), and ICD-10 - It's a family of acronyms that can keep you very busy.

For today, I wanted to continue talking about document management, and share a creative solution I lovingly call the "Poor Man's Document Sharing" strategy.

Now, I generally pride myself on being vendor-agnostic, so please forgive me as I refer to Microsoft's SharePoint, a fairly popular solution to document management woes, although not the only one out there. Again, please note there are plenty of other solutions to this problem, and this is not an endorsement - I'm mainly using SharePoint as a teaching example, so I can explain a particular problem that sometimes plagues healthcare projects.

Anyway, for those of you who don't know what SharePoint (or document sharing software) is, here's a great video that will give you a basic introduction to the problem :



The video really highlights the problems with emailing a document around for discussion and review :
  • It doesn't help organize any discussions - It's very hard for a group to see everyone else's feedback.
  • It tends to create monologues, not dialogues. (Generally from sender to recipients only, not recipient-to-sender, or recipient-to-other-recipient.)
  • It delays the time to developing a good, well-developed, well-reviewed document.
After all, if you are managing any workflow change, you will need to create documents. Borrowing from the CMIO's Checklist, you might need to revise or create documents like :

1. Charters (e.g. Committee Charters, Project Charters)
2. Committee Agendas
3. Committee Minutes
4. Project Plans (e.g. Project plans, testing plans, education plans, etc.)
5. Orders
6. Order Sets
7. Policies and Procedures
8. Clinical Guidelines
9. Clinical Documentation
10. Clinical Protocols
11. Staff Education (e.g. Posters, Powerpoints, emails)
12. Patient Education (e.g. Patient handouts)
13. Spreadsheets
14. Notes

... among other documents/tools that you will need to support your mission.

So how you get people to collaborate successfully will depend on :
  • How you set up your documents
  • How your team uses those documents
  • How you manage your projects
Now, as I said, SharePoint is a fairly popular solution to this problem, although there are other solutions out there too. But what if you belong to an organization that doesn't yet have the resources to purchase such a solution? For those of you who have to make do without, I'm going to present this solution - A basic recipe for The Poor Man's Document Sharing.

The Goal :
To create a standard set of shared folders/documents that your team uses to share ideas and build documents collaboratively.

Ingredients you'll need :
1. An organization with anywhere from 5-500 employees.
2. An organizational computer network with some sort of a shared drive (e.g. the "J: drive")
3. Multiple computers capable of accessing the shared J: drive.
4. A copy of Microsoft Office (2007 or later will do) on each of the computers in #3 above.
5. Some standardized email system that your entire organization uses. (e.g. Outlook)
6. Standardized archetypes of your favorite document types (project plans, policies/procedures, order sets, protocols, guidelines, etc.)
7. A dedicated manager of this solution (e.g. a fearless informaticist) who knows how to hyperlink to a folder and a file.

The Basic Recipe :
1. STEP 1
Set up a shared project development folder on your shared J: drive, one that you plan lots of people to be able to use to work together, for example :
J:/shared/Informatics
2. STEP 2
Create two sub-folders inside this folder :
  • J:/shared/Informatics/templates
  • J:/shared/Informatics/projects
3. STEP 3
Inside the J:/shared/Informatics/templates folder, create the following sub-folder:
J:/shared/Informatics/templates/project templates
4. STEP 4
Inside the J:/shared/Informatics/templates/project templates folder, create the following sub-folders :
  • ./Charter - Drafts/
  • ./Agendas - Drafts/
  • ./Minutes - Drafts/
  • ./Project Plans - Drafts/
  • ./Policies and Procedures - Drafts/
  • ./Clinical Documentation - Drafts/
  • ./Orders - Drafts/
  • ./Order Sets - Drafts/
  • ./Guidelines - Drafts/
  • ./Staff Education - Drafts/
  • ./Patient Education - Drafts/
 ... and fill these folders with your favorite document templates (the ones that your organization uses to standardize the look, appearance, and function of these documents.)
Don't forget :
  • It's helpful if all of your document templates have standardized filenames, like : 
DRAFT - ORDER SET - Standardized Order Set Template - Drafted mm-dd-yyyy.doc
DRAFT - POLICY - Standardized Policy Template - Drafted mm-dd-yyyy.doc
  • If you do not have standardized templates yet, consult your friendly neighborhood informaticist for help developing these!)
You have now built a standard project template, with a standard set of project folders, filled with standardized templates, that you can literally copy-and-paste into another folder, to get any project up-and-running quickly.

5. STEP 5
Now start developing standardized, shared workspaces for your projects. It helps if you create some standard way of organizing them. For example, you might consider creating the following set of sub-folders, based on speciality, where your teams can actually work together :
  • J:/shared/Informatics/projects/Anesthesia
  • J:/shared/Informatics/projects/Emergency Medicine
  • J:/shared/Informatics/projects/Medicine - General
  • J:/shared/Informatics/projects/Medicine - Critical Care
  • J:/shared/Informatics/projects/Medicine - Nephrology
  • J:/shared/Informatics/projects/Medicine - Endocrinology
  • J:/shared/Informatics/projects/Medicine - Cardiology
  • J:/shared/Informatics/projects/Medicine - Gastroenterology
  • J:/shared/Informatics/projects/Medicine - Infectious Disease
  • J:/shared/Informatics/projects/Surgery - General
  • J:/shared/Informatics/projects/Surgery - Orthopedics
  • J:/shared/Informatics/projects/Surgery - Urology
  • J:/shared/Informatics/projects/Surgery - Plastics
  • J:/shared/Informatics/projects/Surgery - ENT
  • J:/shared/Informatics/projects/Surgery - Podiatry
  • J:/shared/Informatics/projects/Psychiatry
  • J:/shared/Informatics/projects/Pediatrics - General
  • J:/shared/Informatics/projects/Pediatrics - Nursery
  • J:/shared/Informatics/projects/OB-GYN
  • J:/shared/Informatics/projects/Radiology - General
  • J:/shared/Informatics/projects/Radiology - Interventional
  • J:/shared/Informatics/projects/Radiation Oncology
  • J:/shared/Informatics/projects/MULTISPECIALTY PROJECTS
* - Note : You will need a "MULTISPECIALTY PROJECTS" sub-folder to put all of the projects that cover multiple disciplines (e.g. MU2, Med Reconciliation, Pharmacy projects, etc.)

6. STEP 6
Give READ/WRITE access to your J:/shared/Informatics folder, to as many clinical directors, chiefs, regulatory staff, quality staff, IT staff, analysts, and other clinical and administrative positions as you can.

This may take some getting used to, especially if you aren't used to that level of collaboration. Remember, that means that everyone you appoint internally will have access to all of your development files, which admittedly carries some risk, but remember - 
  • These are only DRAFT files.
  • This is the "Poor Man's Document Sharing."
7. STEP 7
Need to work on something big like Med Reconciliation? Create a new shared development folder :
  • J:/shared/Informatics/projects/MULTISPECIALTY PROJECTS/Med Reconciliation
... and copy-and-paste the standard project folder, with all of your standardized templates, from :
  • J:/shared/Informatics/templates/project templates
... into your new shared development folder! You will now have a shared working space that your entire team can find easily and work on collaboratively. It will also be full of the standardized templates that your organization has approved, so they can find them and use them easily.

8. STEP 8
Now try to focus all of your discussions on the documents inside these folders - If you want your group to work on a particular policy in a folder, instead of sending your team an email with a copy of the drafted policy, send your team a hyperlink to the drafted policy document in the shared folder.

For example, in the following sample email below, I've highlighted the hyperlinks in yellow :

"Hi team,
In our shared project folder :

J:/shared/Informatics/projects/MULTISPECIALTY PROJECTS/Med Reconciliation

... is the shared policy draft :

DRAFT - POLICY - Med Reconciliation Policy - Drafted 10-22-2013.doc

Please click on the above hyperlinks to :

1. Open the drafted policy.
2. Review the drafted policy.
3. Edit the policy, using Track Changes, if you need to.
4. Add or delete comments to the document.
5. ave the drafted policy document right back into our shared folder.

Please review it and add your comments within the next 48 hours. After we collect comments and feedback from the team, we will schedule our next meeting to review the comments and plan for next steps.

Email me with any questions."

... This then allows your team members to, very quickly :
  • Receive the email from the team leader.
  • Open the document with one click.
  • Edit the document.
  • Leave their comments.
  • Have quick access to help (in case they don't know how to use track changes or add comments, the links about tracking changes, adding comments, and saving a document are all actual links to the Microsoft help pages.)
  • Save the document back to your shared folder.
If two team members try to access the file at the same time, don't worry - Microsoft (and most computer networks) support file-locking : the one who opens it last will get an error message : "FILE CURRENTLY IN USE BY USER __________, would you like to open a read-only version?" which basically helps make sure only one person is working on it at a time.

If someone makes a significant edit, again it's very simple to change the filename and have it save back into your shared project folder. I actually recommend people change the filename if they make any significant edits, and if you use this as your filename :

DRAFT - POLICY - Med Reconciliation Policy - Drafted 10-22-2013.doc

then it is very easy to change it to :

DRAFT - POLICY - Med Reconciliation Policy - Drafted 10-23-2013.doc

Unfortunately, it's also very easy for a team member to delete the working draft, or edit it beyond comprehension. To reduce the risk of this, I usually email myself a "SNAPSHOT - WORKING DRAFTS" copy of the drafts in the team's folder, before I send the hyperlinks out to the team.

9. STEP 9
Been working for months on a policy? Have six different versions in your shared project folder? People getting lost in the folder? Reduce clutter by creating a sub-folder :
  • ./Previous Versions
... and cut-and-paste the older draft versions into the folder. (You might need them for comparison sometime later.)

10. STEP 10
Once you have your project's documents well-built, and well-reviewed by all of the required stakeholders, using your standardized templates, in one common folder - it will probably be very easy to get them approved!

IN CLOSING - This "Poor Man's Document Sharing" recipe may not be the fanciest or most elegant solution, but it does make collaboration a much more organized, standardized, efficient and productive process. 

It's all about making higher quality documents through better communication, improved standardization, and improved productivity.

Like all the posts on this blog, this is for education, fun, and discussion purposes only - Your mileage may vary. Have you developed other ways of collaborating electronically? Any simple tips/tricks I missed? Send me your thoughts or comments!

Sunday, April 14, 2013

Why document management and archetypes matter

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


Graffitti in Northampton, MA, taken December 2012
  
Artwork from Thomas Stanley, age 4 (from Jan 2013)

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


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



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


... by asking yourself :
  • A - Who are the people in the organization?
  • B - What are the documents in the organization?
  • How do A and B interact?
This is why document management matters. Documents are tools - Every document serves a unique function.  So the way you manage your documents and information will, at least in part, determine the actions and behaviors of your employees, and collectively the functioning of your organization :
  • Give them the right tools to express themselves, in the right way, at the right time - and you will empower your directors and managers to make changes in your organization. (WRITE)
  • Publish those tools in the right place, in the right way, at the right time - and you will empower your staff to learn your values, beliefs, and operational standards. (READ)
  • Update those tools regularly, and you will make sure that both your documents and employee behaviors are current, and reflect your ongoing changing needs. (GOVERNANCE)
And so, you want to make sure :
  • Your managers/directors make the best tools.
  • Your tools are published the best way, so people can easily find, read, and learn from them.
  • Your tools are updated regularly.
What exactly are those tools? I outlined some common healthcare-related tools in the CMIO's checklist, but they vary from industry to industry. But what you *do* want to make sure of is :
  • Each tool has a specific, well-defined purpose. (E.g. Apples=Sweet, Onions=Spicy)
  • Your managers have clear guidelines about how to develop the tools (So they grow apples and onions, and don't build a hybrid apple/onion that people are confused by)
  • You have some kind of quality check before tools are published (e.g. to weed out the occasional apple/onion hybrid.)
  • Your front-line staff knows where to find those tools (so they know to find apples in the apple bucket and onions in the onion bucket
  • Your front-line staff knows when and how to use those tools (e.g. apples for baking pies, and onions for making soups).
The reason I bring up the issue about hybrid tools is because, unlike real-world, physical tools - The engineering and safety of paper tools is not quite as intuitive.

For example, a hammer is fairly intuitive :
  • It serves one purpose : To drive in nails
  • Its safety is fairly intuitive : You can see it, touch it, and feel its weight, and once you hit your thumb by accident, you'll quickly learn how not to do that again. 
  • Its utility is fairly intuitive : If the hammer doesn't successfully bang the nail in, you'll quickly know you need a bigger hammer. And it's fairly easy to see that you shouldn't use a hammer to put in a screw.
Paper tools are tricker
  • It might not be as immediately clear if the purpose is vague, ambiguous, or serves multiple purposes.
  • You might not immediately notice any safety issues, or know when the tools is malfunctioning.
  • You might not quickly see if the tool isn't serving its purpose.
This is why it's important to ask yourself about how your paper tools are designed and used. For maximum efficiency, you'll want them to work the best they can - And that means not just designing good clinical documentation, but reviewing it properly, approving it properly, publishing it properly, and monitoring it properly.

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

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


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

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

  • If you wanted a compelling hero template that could serve as a role model (template) for all heroes, to write a blockbuster science fiction movie, then you might make a superhero archetype and name the character "Luke Skywalker".
  • If you wanted a compelling policy that could serve as the role model (template) for all policies, to have a blockbuster policy manual, then you will similarly need a superpolicy archetype to set the example for all of your policies.
(One quick unrelated side note : In this way, I think comic book superheroes actually benefit society - By creating templates/archetypes that kids can use to model at least some of their behaviors. I think this is also why it's unusually heartbreaking to see sports heroes sometimes fall from grace: We hold them up as archetypes of goodness, teamwork and fairness - and then feel great disappointment when we find out that they're actually only human.)

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


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


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

Tuesday, December 11, 2012

Rethinking the Committee Charter

Modern healthcare needs people to work on it. Like a garden, it needs pruning, trimming, weeding, planting, and a lot of care to keep it alive and vibrant. You will probably need committees to help you do this.

Committees are the workhorses of an organization - They help you get things done, hopefully, by coordinating the actions of different parts of your organization, and so they are useful in coordinated change management. From Google :
According to Wikipedia, committees are :
  • "a necessary aspect of organizations of any significant size" and are
  • "a way to formally draw together people of relevant expertise from different parts of an organization who otherwise would not have a good way to share information and coordinate actions" and
  • "can also be empaneled with experts".
The exact parliamentary practices here seems to vary broadly, from Robert's Rules of Order to other blogs and books on parliament, but committees typically come in one of three flavors :
  • Executive Committee - A committee with well-defined executive powers usually spelled out in a charter or organizational by-laws
  • Standing/Permanent Committee - A subunit of a political or deliberative body established in a permanent fashion to aid the parent assembly in accomplishing its duties.
  • Working/Ad Hoc Committee - A group established to accomplish a particular task or to oversee an ongoing area
By the way, for more about committees, see :
Anyway, committees also have their challenges. The problem with committees, generally, is that operationally :
  • You need them to carry out a significant amount of work for your organization, but
  • ...they have to be staffed with several highly-trained people, and so ...
  • ... if they're not run efficiently, they can be a drain on resources.
So ideally, you want a committee to be well-run, efficent, and productive

How to get a committee to be well-run, efficient, and productive?

I find one of the most challenging things when creating a committee is defining the committee to achieve clarity. So I looked at some of the most common questions I hear about committees : 
  • Why does it exist?
  • Who created it? When?
  • Who's going to run it?
  • Who's going to participate in it?
  • What powers/authority does the committee have?
  • How often will they meet?
  • Who will it report to? Who will oversee it?
  • How will it vote? Who will vote?
  • What's the quorum?
And so to help achieve clarity on these issues, I rethought the "Committee Charter", and drafted the following sample one-page template :
This DRAFTED charter template, in one page, then facilitates operational clarity by encouraging both committee members and the overseeing body to define their terms, and agree to :
  • Committee mission (Why is the committee needed?)
  • Committee responsibilities (What is the expectation for this committee?)
  • Committee chairperson(s) (Who will run this committee, set the agendas, conduct meetings, ensure minutes are kept and approved, and report the activities/actions of the committee?)
  • Committee membership (both voting and non-voting members - Who can vote? Who can't?)
  • Meeting frequency (How often will this committee meet?)
  • Delegated authorities (e.g. "to send emails on behalf of another person/committee"?)
  • Voting Type (How will the members approve motions?)
  • Quorum (What's the minimum number of people that need to be in a room for an official meet?)
  • Charter Review (How often will this charter be re-examined? When will it be reapproved?)
  • Measures of success (How will we know if the committee is effective?)
  • Oversight body (Who will this committee report to?)
It's pretty short-and-sweet, but in one page I think it gets the job done quite well. As always, if my writing inspires you, remember to tailor it to your needs. Let me know if you have any other charter templates you like, and why you use them!

Remember, this is all just academic discussion, and your mileage may vary! Check with your local regulatory bodies before developing governance tools in your area. Feel free to send thoughts, comments, or questions - I always enjoy getting feedback from other people looking to improve healthcare!

Wednesday, November 28, 2012

What exactly is "Alert Fatigue"?

Clinical Decision Support (CDS) - It's the mythical creature that every healthcare administrator and informaticist is hunting, to help reduce costs and improve care. Loosely, it can be broken into a few different areas :
  1. Electronic decision support (e.g. CPOE Alerts to help prevent errors)
  2. Order / order set design (e.g. to help prevent errors / guide docs to evidence-based care)
  3. Workflow/documentation redesign (e.g. tools used to standardize high-risk decisions, e.g. procedure checklists)
  4. Workflow/protocol design (e.g. tools used to automate high-risk procedures)
One of the hardest to tackle is #1 - CPOE Alerts. Are there too many, or too few? Everyone I know seems to be struggling with the same issue :
  • Wanting to provide CPOE alerts to avoid errors, but
  • Providing "too many alerts" could cause docs to ignore the "important alerts".
This phenomenon is loosely called alert fatigue, and has been fairly well-documented in literature as, paradoxically, a potential risk
When you hear Informatics professionals discuss alert fatigue, the challenging part is actually knowing when alert fatigue exists. Docs sometimes complain about it, but the response docs get to this is often skepticism - After all, how can an alert be bad? Maybe the doc just complains too much? And who is going to turn off the alert? Is it safe to turn off the alert? What if this opens up other problems? When is it too much? When is it too little?

So when you ask docs to define alert fatigue, they typically use general, loose definitions, like :
  • "It's when the system gives me too much information and I miss the important stuff."
  • "It's when the system tells me about the Tylenol interacting with Colace, but I miss out on the Coumadin/Bactrim interaction."
  • "It's when I can't read all of the alerts."
  • "It's when I just keep clicking 'Bypass' without actually reading the alert."
  • "It's when I just keep clicking 'Acknowledge' without actually reading the alert."
  • "It's when I click 'bypass' within 3 seconds, so I know I didn't read the alert."
And recently, when I asked some informatics colleagues for their definition of alert fatigue, I again got a myriad of responses, followed by the same sort of response Supreme Court Justice Potter Stewart gave in 1964, when defining "obscenity" in the Jacobellis v. Ohio case : "I know it when I see it."

Unfortunately, this doesn't help much for those of us who are really working to combat alert fatigue
The problem with all of these definitions is that they are fairly loose and subjective, and don't make a good litmus test to answer the question : Do you have alert fatigue?

So I'm going to use some reason and inference, to try to develop a better definition of alert fatigue that is quantifiable. (I used to be a mathematician/statistician, so please forgive the quasi-mathematical approach.)

Since it seems the "undesired scenario" nobody wants is made up of two steps :
  • An EMR providing a confusing alert environment, and
  • A doc displaying signs of poor response to that environment
So I'd like to submit two proofs, for two conditions which then go into a third proof. Here they are :

PROOF1 : "AlertOverload"
1. [AlertOverload] = [Bad] > [Good]
2. [AlertOverload] = [Noise] > [Signal] 
3. [AlertOverload] = [Low-value alerts] > [High-value alerts]
4. [AlertOverload] = [Low-risk alerts] > [High-risk alerts] 
5. [AlertOverload] = [# of low-risk alerts] > [# of high-risk alerts] 
6. [AlertOverload] = [Number of low-risk alerts in a time period] > [Number of high-risk alerts in a time period]
7. [AlertOverload] = When the number of low-risk alerts exceeds the number of high-risk alerts for a given physician in a given time period

PROOF2 : "AlertLoss"
1. [AlertLoss] = [Bad] > [Good]
2. [AlertLoss] = [BypassedAlert] > [AcknowledgedAlert] 
3. [AlertLoss] = [Number of bypassed alerts in a given time period] > [Number of acknowledged alerts in a given time period] 
4. [AlertLoss] = When the number of bypassed alerts exceeds the number of acknowledged alerts in a given time period

If one were to accept proof #1 and #2 as true, then I would propose this final proof/definition of AlertFatigue :

PROOF3 : "AlertFatigue"
1. [Bad] = [Bad] 
2. [AlertFatigue] = [Bad]
3. [AlertFatigue] = [AlertOverload] + [AlertLoss] 
4. [AlertFatigue] = Exists when a given physician experiences [AlertOverload] and displays [AlertLoss] in a given time period

So voila - My proposed definitions :

  1. Alert Overload = When the number of low-risk alerts exceeds the number of high-risk alerts for a given physician in a given time period
  2. Alert Loss = When the number of bypassed alerts exceeds the number of acknowledged alerts in a given time period
  3. Alert Fatigue = "When a given physician experiences alert overload and displays evidence of alert loss in a given time period."

It's certainly not a universally-recognized definition, and I'm curious if other people are aware of any other professional, practical, policy-grade definitions that exist out there. Obviously, this definition now needs to be peer reviewed, tested, validated, and professionally accepted, so please don't use it in your own organization without consulting a legal professional, informatics professional, and your local regulatory agencies first.

Remember : As always, this discussion is for educational purposes only! Remember, your mileage may vary! Always enjoy thoughts, comments, and ideas!

Wednesday, August 29, 2012

Recipe for baking matching electronic and paper downtime order sets

EMR downtimes occur. Hopefully not often, but when they do, you'll want to make sure you have order sets for your docs to use. If you don't have downtime order sets, easily available for them to use, you'll probably notice a downgrade in their clinical efficiency, as they struggle to write out all orders by hand from scratch.

Much has been said about physician over-reliance on order sets, but the truth is that they become tools that physicians rely on, much like a carpenter might rely on an electric screwdriver to help put in screws. In a downtime, could the carpenter make do with a manual screwdriver, or a Swiss Army knife, for that matter? Sure. But you want to keep things running smoothly and predictably, so it's helpful if there are order sets available during downtimes.

The problem is, it's sometimes hard to maintain paper downtime order sets. Some reasons include :
  • After a hospital "goes electronic", the focus of order set development is often the electronic order sets.
  • Not all EMR software has functionality to "print out" an order set.
  • Sometimes, printing out an electronic order set makes a funny-looking order set that docs may not intuitively know how to use
  • The exact functions and formats of the paper and electronic order set, often, do not entirely match.
So it's easy to leave the paper order sets behind, as you work to optimize your order set strategy.

And this is why I've been asked, "How can I consistently make matching, high-quality paper and electronic order sets?"

Here's my recommended recipe. You may want to add some touches, depending on your needs.

THE BASIC RECIPE :

Ingredients - What you'll need :
  • A standard EMR, chock full of well-built electronic orders.
  • standard word processor and hard drive.
  • A standard Order Set template, to help the Clinical Informaticist maintain consistency in order set headings and order types.
  • A standard indexing system for your order sets, so you'll know how staff will search, find, and track them (e.g. "Order Set #1" vs. "ABC-123" vs. "Pneumonia Order Set")
  • A standard Order Set Style Guide, to help the Clinical Informaticist make sure the format all looks the same.
  • A Clinical Informaticist, willing to help examine workflows and draft paper order sets.
  • A Clinical IT Analyst, willing to help build electronic order sets in your EMR.
  • A Clinical Director, willing to own (test, monitor, maintain, and educate) the order set and round up end-users for testing.
  • An electronic page on your Intranet where you'll publish your paper order sets for electronic downtimes.
  • Some end-users to help test your order sets (e.g. a willing physician, nurse, pharmacist, and/or other users).
INSTRUCTIONS FOR BAKING :

STEP 1 : Clinical Director determines need for an order set and asks Clinical Informaticist for help.

STEP 2 : Clinical Informaticist examines workflow, and ensures resources (ingredients) are available for development.

STEP 3 : Clinical Informaticist decides on category for order set :
  • Admission Order Set (e.g. "Admit to ICU", "Admit to CCU", "Admit to Med/Surg")
  • Diagnosis Order Set (e.g. "Pneumonia Order Set", "Knee Replacement Order Set", "CHF Order Set")
  • Convenience Order Set (e.g. "Hypercoagulable Workup Order Set", "Blood Transfusion Order Set", or "Insulin Drip Order Set")
STEP 4 : Clinical Informaticist names the order set and uses a standard word processor and electronic orders to create a DRAFT paper order set :
  • Name the DRAFT paper order set according to proper category (from Step 3 above), index it properly, and label it "DRAFT".
  • Use your organization's standard order set template and style guide to start!
  • Look up each electronic order in the EMR, and review the function and necessary fields in the electronic order.
  • Create a matching paper order, with those necessary fields.
  • Gradually start to collect those matching paper orders to draft a paper order set that matches the standards in your electronic orders.
  • Any discharge instructions? Put them on a drafted discharge instruction sheet!
  • Any protocols? Put them on a drafted protocol sheet!
STEP 5 : Clinical Informaticist gives the drafted paper order set over to Clinical IT Analyst to build a matching DRAFTED electronic order set in TEST system. (Because the Clinical Informaticist used the standards of the electronic orders, when making the paper draft, this will be very easy to do!)

STEP 6 : Clinical Informaticist and Clinical Director now review the :
  • DRAFTED paper order set (labeled "DRAFT")
  • DRAFTED electronic order set (in TEST environment)
STEP 7 : Clinical Informaticist, Clinical Director, and end-users (usually a minimum of physician, nurse, and pharmacist) "test" both paper and electronic order sets using some realistic "mock scenarios"
  • Consider collecting any "testing" data, e.g. physician/nurse/pharmacist satisfaction, time-to-completion, etc.
  • If any changes arise during testing, Clinical Informaticist and Clinical IT Analyst can correct both paper and electronic order sets simultaneously, to make sure they match.
STEP 8 : Once testing is completed, Clinical Informaticist and Clinical Director develop education and go-live plan for order sets.

STEP 9 : Clinical Informaticist and Clinical Director present, to your organization's formally-chartered approval committee :
  • DRAFTED paper order set (labeled "DRAFT")
  • DRAFTED electronic order set (in TEST environment)
  • DRAFTED discharge instructions (if any exists from step 4 above)
  • DRAFTED protocols (if any exists from step 4 above)
  • Testing results/data
  • Educational Materials
  • Go-live plan
for their final review and approval.

STEP 10 : After approval, you remove the "DRAFT" label from the paper order set and publish :
  • Paper order set - Put up on your intranet "Downtime Order Set" page, or some other common location your staff agrees to look for during electronic downtimes.
  • Electronic order set - Move the draft from your TEST to your LIVE/PROD system.
STEP 11 : Clinical Director will deliver education, and continuously monitor the order set for safety, effectiveness, and new evidence/regulations.

STEP 12 : Clinical Director will return to step 1 as needed!

Bake at 350 degrees, or until golden brown!

I'm always interested in discussion! Feel free to leave comments about your process for developing matching order sets for your downtime! Questions are welcome!

Wednesday, June 13, 2012

Med Reconciliation and Midlevels

Sorry folks - I know it's been a few weeks since my last post. Blogging is fun, but it's hard work. New CMS regulations on Order Sets, Meaningful Use, HIE, EMR/EHR... It keeps a CMIO busy!

Anyway, so now onto this post. Working in front-line applied medical informatics, I see some general healthcare trends evolving. Some are predictable, other's aren't. Here's one of the things I've noticed recently, that might be encouraging to the midlevels (PAs, NPs, CRNAs, and Midwives) in the audience.

What I'm seeing : As three trends merge -
... it's becoming very clear to me that the demand for accurate electronic med reconciliation practices will go up inside hospitals.

The problem is that this is not the always the easiest thing to do. Just assembling medications and allergies at the point-of-entry can be complicated, having to potentially reconcile up to seven data sources (patient, family, PCP, specialist, pharmacy, chart, and med database). Many hospitals hire a position (pharm tech, or other equivalent position), just to compile the list of home medications.

But then, once you have the list, entering them into an EMR can be a challenge.

Once you have them in the EMR, then, you can perform electronic med reconciliation. It's one thing to do it at the point of admission and discharge to your hospital - It's another to do it at every transition of care.

But knowing that the goal is for med reconciliation at every transition of care, I sometimes wonder : Who will do this, and how? Especially in some areas where there are frequent transitions of care (e.g. your perioperative areas), how will you manage those medications?

Some feel surgeons should be responsible for med reconciliation of their patients in the perioperative period. The challenge, however, is that surgeons are often under intense pressure to get back to the OR, or else there are OR delays which cause a whole different set of issues.

It's also common for anesthesiologists to care for patients in the post-operative setting - But again they face pressure to go back to the OR, to avoid delays, so they mainly only focus on the immediate medication needs of the patient.

So it's not unusual for the conversation to then lead to hospitalists managing the medications for the surgical patients, especially in the post-operative period. (After all, who better to manage medications than someone trained in a medical specialty, right? :) )  The challenge here is often that hospitalist services may not be able to handle the additional workload, without expanding their workforce, and hiring an extra hospitalist can be pricy.

And so, I suspect many organizations will start to look at midlevels as a more cost-effective way of  helping to fill this need. And so, my impression : The demand for midlevels (PAs, NPs, RNAs, Nurse Midwives) will continue to increase in the near future.

How much will it increase? I suspect as long as midlevels are more cost-effective than hospitalists, the demand for them will go up. So if I wanted to play futurist, I would guess the increased demand would drive midlevel salaries up until they reach that of an average hospitalist - and at that point I think the demand would level off :


Of course, this trend will depend on many factors, including regulatory issues, licensing/credentialing issues, physician supply issues, and other state and federal controls on physician and midlevel training. And my prediction could be totally wrong! I'm going to keep scanning the horizon, but I suspect the healthcare organizations of the future will use midlevels with a solid oversight and supervision model, that allows them to give high quality care for less.

Any dissenting opinions? Feel free to comment below!