Strong Recommendations for new Applied Clinical Informaticists, Part 2 of 2

 Hi fellow CMIOs, CNIOs, and other Applied Clinical #Informatics and #HealthIT friends,

Today, I thought I'd share the second half (next ten suggestions) of my general advice to new Applied Clinical Informaticists, and other people interested in smooth clinical #workflow design. 

Strong recommendation #11 (of 20) below involves understanding the inseparable, symbiotic relationship between Information Technology (IT) and Information Science (IS), the discipline that drives Applied Clinical Informatics. While it's tempting to think only one is more necessary or relevant than the other, they are both equally necessary and relevant - You cannot have one without the other. 

Coming in at #12 is the strong recommendation (below) to understand the difference between the 'seeds' of good ideas, and the 'soil' (operational infrastructure) necessary to grow those seeds. While operational infrastructure is not always a high priority, neglected infrastructure can lead to frequent project delays, project failures, and inability to move forward. Take some time every year to look carefully at operational infrastructure, and make sure you devote the time and resources necessary to be able to grow the seeds of good ideas. 

Strong recommendation #13 (of 20) below sometimes becomes more visible after a few years in Applied Clinical Informatics, but it addresses the relationship between inconsistent or incomplete workflows, and burnout (moral injury). Especially in routinely high-risk, high-stress operations, your clinical teams will always appreciate having a smooth, predictable, well-understood pathway (workflow) from problem (point A) to solution (point B). Tangled, confusing, or incomplete workflows only create stress and confusion. Having well-designed, well-developed templates will help you make sure you're covering all of your bases, and that every step of your workflow is well-planned, clear, and complete.

My next strong recommendation (#14 of 20) below is just to be prepared to answer common questions about "Why do we need an interdisciplinary Applied Clinical Informatics team?" While there are many reasons, six of the most common include :

1. Project Intake / Procurements that require additional support or workflow analysis / evaluation to help ensure the technology doesn't already exist (in your organization), and to help ensure proper scoping, budgeting, stakeholder identification, resource allocation, alignment with safety or compliance needs, and expected outcomes. 
2. Special Event Workflow Planning (e.g. Planned maintenance or unplanned downtimes, planned upgrades, or project go-lives)
3. Complex IT Tickets that require workflow updates / modifications (often span areas with multiple stakeholders)
4. Complex Projects that require clinical translation, terminology work, stakeholder identification and alignment, or workflow updates/modifications.
5. Ongoing maintenance of existing configuration / workflows to meet CMS/TJC regulations (and other payer and user requirements), that requires continuous staff engagement with multiple stakeholders across different areas/specialties. 
6. Helping to ensure clinical workflows are aligned with the clinical, HIM, coding/billing, and revenue capture needs of the organization.

To have the skills and expertise necessary for these common functions, you will need an Applied Clinical Informatics team. Knowing some good reasons to have such a team will help support the discussions about how to build one. 

Strong recommendation #15 (of 20) for new Applied Clinical Informaticists (below) is to really care about design. Cooking food is not enough, you need to care about cooking great food. While discussing details is sometimes seen in healthcare as 'getting too into the weeds', our clinical teams need you to care about the details, so that you can develop the complete blueprints that will help technical teams to build great workflows. Also : Try to resist the urge to use short-term solutions for long-term problems - While they might temporarily help, they usually create workarounds that then need even more work to fix.

At #16 is my strong recommendation (below) to know the sixteen (16) most common (CPOE) order types. These are the basic building blocks that work together to build all of your clinical worfklows. It's very helpful to know what they are, what they do, how they work together, and when to use them. Many incomplete workflows come from not including one or more of these order types in an order set, order panel, or other ordering tool, so you can help improve workflow design by including all sixteen order types in an order set template, and then using that to guide the development of all of your order sets. *Note : Not every order set will use all sixteen order types, and you will only use the ones you need to address your desired clinical scenario. Having all sixteen types in a template (for developing your order set blueprints) will help create consistency and completeness for your clinical teams. 

My strong recommendation #17 (of 20) below is simply not to minimize the complexity of ordering tool ('order set') requests. I'm often fascinated by the small requests that have the largest operational impact, and thus require more time and effort to plan and execute than most people have budgeted for. Setting realistic expectations is the first step to good planning, so do your worfklow (gap, current-state-future-state) analysis early, and be prepared to inform your requestor when a project is larger than originally anticipated. 

Strong recommendation #18 (of 20) below is simply to consider how you will manage the intake of maintenance tickets and new project requests, from a variety of stakeholders. Navigating HealthIT (and Applied Clinical Informatics) often means managing the competing interests of : 

• Software vendors
• Patient/Caregiver input/feedback
• User input (from multiple stakeholders)
• Contracting and Payer Updates
• Formulary Updates
• Practice Onboarding
• Institutional Decisions
• Federal, State, and Department of Public Health regulations
• Evidence-based best practices
• Institutional policies and bylaws
• Privacy and Security Needs
• Quality Reporting
• External advisory organizations (e.g. The Joint Commission, Leapfrog, etc.)
• Vendor choices

... so you will want to consider all of these potential sources of change in your intake and prioritization processes.

Nearing the end, my strong recommendation #19 (of 20) below is to learn the most common types of Computerized Provider Order Entry (CPOE) order modes. Ideally, providers would always enter their own orders, but there are some very important, very legitimate reasons (clinical scenarios) why they sometimes cannot (without delaying necessary patient care). Understanding these reasons (and scenarios) will help you create and support compliant and safe order entry workflows all across your organization.

Finally, my strong recommendation #20 (of 20) below is simply to empower a clinical leader. Whether they are a nursing leader, physician leader, APP leader, radiology leader, laboratory leader, pharmacy leader, or other ancillary staff leader - they are all important and deserve your support. Usually, they are already great clinicians - Help them learn leadership skills, and they will be better leaders, and help you solve more problems. Skills like : 

• Reading a bylaw / policy
• Writing a bylaw / policy
• Reading a budget
• Planning a budget
• Writing a charter
• Chairing a committee
• Planning an agenda
• Project and change management basics
• Documentation and coding basics
• Hiring a staff member
• Managing a staff member

... can go a long way to long-term success for any leader. If you see a new clinical leader, make sure you reach out to them and support them as they grow - This will help empower leaders to retain staff and solve problems.

Okay, along with my first ten recommendations, I think these additional ten above cover my top twenty (20) strong recommendations for new Applied Clinical Informaticists seeking to design smooth workflows. If you have other suggestions, please leave them in the comments section below!

Remember - This blog is for educational and discussion purposes only, and is not formal advice - your mileage may vary. Have any other helpful ideas, suggestions, or experiences you'd like to share? Feel free to leave them in the comments section below!

Untangling Workflows - The Cupcake Test

 Hi fellow CMIOs, CNIOs, and other Clinical Informatics friends,

As I mentioned in my last post, I recently had the opportunity to share some workflow design tips with an online group of new physicians who are getting into Applied Clinical Informatics and workflow building. During my talk, I shared some helpful workflow tricks that I use to untangle even the most complex clinical workflows. Even though I've written about this one before, it's so useful I figured I should re-review and elaborate with this new audience. 

One of my favorite tricks is this very simple one with pretty impressive impact. It's basically just writing a technical procedure, but with a little more detail. I affectionately call it, "The Cupcake Test", because it uses good procedure writing to help answer the metaphorical question - Does this 'cupcake recipe' (or 'cupcake workflow') actually bake a cupcake?

Writing a good technical procedure can be a helpful substitute for the common Visio swimlane diagram that seems to be more of a popular industry standard. From my recent presentation : 

To understand how good procedure writing can be used as a substitute for Visio swimlanes, I need to first explain two important concepts that are necessary to understand before writing a procedure that passes the 'Cupcake test' : 

• What is a TASK?
• What is a PROCEDURE? (Synonyms : Workflow, recipe, process)

And so from my presentation, my slide showing the definitions of both : 

Using these two definitions, and the procedure template outlined above, we can now write a simple and clear technical procedure, and even color code it to help quickly identify and align concepts. Here's a sample of what it looks like : 

While this approach is not exactly an industry standard, there are some pros and cons to using it : 

And in my experience, a good procedure can usually be quickly and easily converted to a good swimlane diagram - But sometimes swimlane diagrams can't be as easily converted into good technical procedures that pass this 'Cupcake Test'. That is, they are not written with the template : 

TASK = [WHO] will/may [WHAT] {how} {where} {when} {why}

... in each line of the procedure. 

Not only does this approach include the benefits listed in the slide above, but it's easy to teach, and it also helps you easily generate cost estimates of workflows/procedures before you build them.

Next time you have a complex workflow you're trying to figure out - just start by writing good technical procedures, and the workflow will start to immediately reveal itself right in front of you. If you have any experience with using this approach, please leave it in the comments section below.

Remember - This blog is for educational and discussion purposes only - Your mileage may vary. If you have any feedback or questions, or experiences writing workflows or technical procedures, feel free to share them in the comments section below. 

What is your EMR documentation index costing you?

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

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

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

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

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

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

[ START OF RESPONSE ] 

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

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

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

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

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

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

Where :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hope this helps! Good luck!

- Dirk :)

[ END OF RESPONSE ] 

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

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

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

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!