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!

Secrets of EMR Governance

The following is essentially a repost of the piece I wrote for the June 2012 HIMSS Insider, with some slight modifications for my blog. (My apologies - my blog allows a higher word count!) :) :

Implementing an Electronic Medical Record (EMR)? Then you’ll want to know something about EMR governance. It’s a subject that’s not well-understood, but in this article I’ll try to provide some background. EMR governance is the process by which you standardize your clinical practices and set them up to work electronically. Without predictable clinical practices, you won’t be able to get predictable clinical outcomes - and because computers are programmed to behave predictably, your EMR implementation will be challenging.

What is governance? 

Although the Oxford dictionary defines governance as “the action or manner of governing,” a quick Google search reveals this NIST (National Institute of Standards and Technology) definition:
“…the controls and processes that make sure policies are enforced.”
So why should clinical professionals worry about policies? After all, aren’t they documents that administrators are paid to worry about?

What is a policy? 

The reason clinical professionals should care about policies is because they are the central nervous system that quietly controls your organization.

Policies are essentially your organization’s standards. They reflect your values and describe, in writing, what you’ve decided to do. If your standard is to give all patients a gluten-free, diabetic cupcake on admission, then your organization could decide to write that standard down on a piece of paper :

“All patients will get a gluten-free, diabetic cupcake on admission.”
Of course, you may decide to pursue more meaningful standards, but for now we’ll use this simple policy as a teaching example.

What is a procedure? 

If a policy describes what you do, then the procedure describes how exactly you go about doing it.

A good model for a procedure is a food recipe. Every line contributes to the end result. For example, to describe how to achieve the cupcake policy above, you might write this procedure:

  1. Kitchen staff will bake 100 gluten-free, diabetic cupcakes daily.
  2. Couriers will bring cupcakes to floor.
  3. Nurses will give cupcakes to patients on admission.
You’ll notice a common theme in the procedure above: Each line answers, at a minimum, the who and what, but also can explain the when, where, why, and how
PLEASE NOTE : Some legal advisors recommend avoiding “will” and substituting other terms like “should” and “may.” Check with your legal counsel for advice before writing policies.

Then by having the directors of the Kitchen staff, Couriers, and Nurses review the policy before it gets approved, it allows them to :

  • Review the expected workflow - so they can educate it to their staff once the policy is approved, and 
  • Budget for it - Do they have the staff and material resources to uphold their part of the workflow?
You will want the directors and their staff to review the drafted policy before it gets approved, so be prepared to spend some time reviewing it with them before it goes for final approval.

When do I write a policy and procedure? 
By writing your policy standard and a procedure describing exactly how to achieve that standard, you now have a very valuable document. Together, these documents give you a meaningful change management mechanism.

Some people, when they learn about policies and procedures, suddenly want to develop policies for everything. Try to resist this urge. Too many policies can make it hard for employees to comply with them. On the other hand, too few policies might mean you’re not standardizing your operations. Ideally, you want a happy medium.

And so, you should only write policies when:

  • The policy is required to meet a legal, regulatory, safety, or operations need.
  • The policy addresses a common occurrence or practice.
  • You have the resources to implement the policy.
  • You can enforce the policy.
And, you should only write good policies.

What’s a good policy? 

A good policy is one that creates clarity and harmony in your organization. End-users should be able to find it, read it, and immediately understand your expectations. It should be a valuable management tool for leaders and directors, and should always reflect your values and current practices.

A bad policy is one that creates confusion, chaos, or in a best-case scenario, changes absolutely nothing. A bad policy conflicts with your values, does not reflect practice, is published where few people can find it, and many employees don’t know it exists.

So what about hospital governance? 

Before discussing IT and EMR policies, it helps to understand a little about the difference between administrative and clinical policies.

Let’s say you were building a hospital from scratch—you would need two teams to help you :

  1. A clinical team, who know all about giving care, treating diseases, and doing surgeries and procedures
  2. An administrative team, who know all about finance and operations and regulations and legal issues.
Neither team can live without the other; virtually all hospitals need both. So we generally divide their standards into:
  1. Clinical policies – Those that define patient care and clinical standards.
  2. Administrative policies – Those that define employee and administrative standards.
The key ingredient needed for these two teams to work together harmoniously is good communication at all levels of your organization.

So what about IT and EMR Governance? 

After you have a good understanding of your organization’s policy and committee structure, you can go about examining your current standards. Do you have any documents that spell out basic clinical practices such as:
  • Electronic Documentation – How/when to create it, sign/authenticate it, use it?
  • Medication Order Standards– How/when to order certain medications? Non-formulary medications? In code blue/emergency situations? Over the phone?
  • Standards for lab/radiology orders– How/when to order certain tests?
  • Training standards – How do you train new employees? Existing employees?
  • Clinical Tool Development – How do you develop order sets? Policies? Procedures? Protocols? Documentation? Downtime documentation?
Look for these documents because you will need to examine them and probably modify them after your EMR implementation to help make your processes more efficient. In general, the standards get tighter, and the demand for resources increases after your EMR go-live.

Finally – A common question I hear is, “Where should I publish my IT and Informatics policies? In the administrative or clinical policy manual?” Surprisingly, most informatics and clinical IT policies belong in the clinical policy manual. While it’s tempting to think of them as administrative issues, most of them have a strong impact in clinical functions and strongly impact the day-to-day operations of clinicians. When in doubt, ask yourself: “Who is the end-user of this policy?

10 DOs and DON’Ts to remember with EMR and Health IT Governance

  • DON’T: …write policies in a rush. The more time you spend on them, the clearer and more effective they will become.
  • DON’T: …write too many policies. They should only be for things that address absolutely necessary legal, regulatory, or workflow issues, and those that you have resources to monitor and implement. 
  • DON’T: …make policies automatically punitive. Non-compliance with a policy should give a leader a reason to pause and reflect: Why didn’t the policy help reinforce the desired outcome?
  • DON’T: … forget to document reasons why you knowingly didn’t comply with a policy. They carry legal risk and weight, so any non-compliance should be well-documented and discussed with leadership.
  • DON’T: … keep policies hidden! For them to work best, it helps to keep them in a common place where everyone can find them.
  • DO: … practice writing policies, and have end-users look them over to help check for clarity.
  • DO: … spend time learning your organization’s governance structure, including your bylaws, policy manuals, policy writers, reviewers, and approval bodies.
  • DO: … keep reading more and look for classes on operations and policy development.
  • DO: … consult legal counsel when needed, especially to tackle tricky, high-risk or other compliance issues.
  • DO: … network with other healthcare technology colleagues, to share tips, tricks, and lessons learned.

Sunday, April 1, 2012

CMIO Survival Skills

While a CMIO is there to help implement the technology, so much of the job is process, workflow, and governance. So since I've now been in the role for five years now, I thought I'd take a moment to look back and reflect on the things I've learned in the last five years that I think are valuable CMIO skills.
Here are the 13 most important skills I can think of, off the top of my head, in my usual tongue-in-cheek style : (Remember, as always - Your mileage may vary, depending on your circumstances.)
  1. Hospital Governance 101 -  It's not enough to just know the clinical side of governance. You need to know the administrative side too. Both of these wings of hospital governance intersect with each other in different places, and knowing where they meet with your bylaws is vitally important. You will be navigating both, so it pays to know the landscape. Bonus points are awarded if you can diagram your committee structure by heart. :)
  2. Document Management - Understanding the basics of how documents are created, drafted, approved, and published is essential. Bonus points are awarded for knowing the details of these steps well - For starters, I wrote a post on the importance of knowing the difference between DEV, TEST, and PROD - These environments typically exist for computer projects, but in reality they apply to all construction and document development (even that email you just sent!). Know them well, why they exist, and how to use them to your advantage in your organization.
  3. Definitions and structure of your Clinical Tools - You should know your clinical tools like the back of your hand - Exactly how your organization defines them, drafts and builds them, tests and reviews and vets them, approves them, and publishes them. You should be able to look at them and have opinions on whether they are as effective as they can be. For starters, the CMIO's checklist is a good place to start working on this. Bonus points are awarded if you can recite your organization's definitions off the top of your head. :)
  4. Compliance with State and Federal Regulations - You will need to know these well, and will probably be asked to help your organization comply with some of them. Even if you don't know them very well, you need to have a good relationship with your regulatory people, and know where to look when you have questions. Bonus points are awarded as you gradually learn this landscape better.
  5. Project Management and managing 'the technical details' - You will need to know the basics of this - Whether or not you have a separate project manager to work with, you will be involved in many projects. Knowing what to expect at different stages when undertaking large month- and year-long projects is very helpful. As for the technical details, you may not want to know how sausage is made, but if you (or your organization) wants to eat sausage (pardon the metaphor), then someone will have to worry about the technical details. If it's not you, then make sure you have a good relationship with the people who understand the details, and work with them closely when undertaking new projects. 
  6. Parliamentary Basics - You will probably be asked to chair a committee or two, and be a member of others. Knowing how to properly run a meeting and conduct a committee is crucial. For starters, Robert's Rules of Order is a fantastic place to start. Also make sure you have a formal, written charter - It not only establishes your authority, it establishes the chain-of-command and is essential for good performance and when questions come up. And a tip : Always publish your minutes after approving them at the next meeting. If you wait to format and approve your minutes, they will just build up and you'll have to play catch-up later.
  7. Meaningful Use, emerging Health IT Trends, and Workflow Analysis - It's almost impossible to keep on top of every detail, but you should have a good understanding of the Meaningful Use rules, timelines, and how your organization is responding to them. You should also understand the basics and be able to comment on various existing and emerging HealthIT, clinical, and legal trends, including your statewide HIE effort, NHIN, ICD-10, clinical decision support, mobile devices, HIPAA, eDiscovery, etc. Finally, you should understand the basics of workflow analysis and why it's necessary to implement all of this technology. A good way to learn to think in a linear fashion is to read food recipes - This will help you think about the relationship between process and outcomes, and help teach you to write a good procedure.
  8. Safety through Information - Safety is not just resident workforce hours and barcoding your medications. Safety needs to be built into all of the documents and information you're overseeing. First, know what a good order set and a good protocol look like - Then learn what good documentation, good policies, good procedures, good guidelines, and good workflows look like. This is one of the big reasons organizations look for a CMIO, so always look for opportunities to improve safety with every tool you see.
  9. Networking - Virtually every hospital is going through Meaningful Use together. You will help save yourself a lot of headache if you know the other CMIOs in your area. Use social networking (e.g. Twitter), or call them up, introduce yourself, and meet them just to talk shop every once in a while. The Interstate 91 Informatics group I've set up has been invaluable to me and others in helping to share lessons and best practices. Look to see if there's any regular gatherings in your area, and try to get to at least one of the national conferences every year (e.g. HIMSS).
  10. Teambuilding, cheerleading, politics - You will undoubtedly meet other doctors, nurses, pharmacists, and other ancillary staff, and need to meet with them. Often, EMRs demand more collaboration between clinical specialties, so you will have to know how to encourage people to work together. Don't try to play sides or favorites - Treat everyone equally and you'll be able to build those teams.
  11. Budgeting realities - Implementing an EMR is expensive. There are costs at every step of the way - Technical costs, training costs, costs to change workflows, staffing costs. "Flexible budgeting" is optimal, but in today's climate, most organizations are focused on cutting costs. Be prepared to work with your budgeting people, and always ask yourself, "What if we don't get everything we ask for?"
  12. Informatics Education - Whether you're the "Chief Medical Information Officer" or the "Chief Medical Informatics Officer", you will be discussing Informatics with many people, probably while you are defining this emerging role in your organization. The term is sometimes frightening to people, until they start to understand it. Don't try to teach too much at once - Small, frequent feedings are better, so try to meet with leadership for frequent, short meetings. Bonus points are awarded if you help set up an entire Informatics department.
  13. Statistics and Process Improvement - After your EMR go-live, you will probably be asked to help optimize the EMR - That means, looking at the results from go-live, and looking for ways to improve results, e.g. higher achievement of core measures, higher CPOE rate, etc. Learn how to get utilization data out of your EMR, and look for statistical relationships that help you improve your processes. Know what a Venn diagramcontrol chart, pareto diagram, and fishbone diagram are. Bonus points are awarded if you can write your own SQL code! :)
It has been enormously rewarding to me, and if you find yourself in the role, I hope it's equally rewarding to you. Although the first CMIOs appeared on the scene back in the 1990s, it's still a relatively new position (especially in the northeast), so be prepared for a lot of change and ambiguity when you start down the road. 

As always, I enjoy simultaneous teaching and learning - Feel free to leave questions, comments, or thoughts below!

Wednesday, March 28, 2012

Linguistic issues in Healthcare

I'll admit it - I was flattered when Mark Hagland of Healthcare Informatics recently gave me my second interview about CMIO life. During our discussion, he asked me a lot of questions about "What does it mean to be a CMIO?" and "What makes a good CMIO?". And as I was responding, I told him that I feel like a lot of my job is about offering translational services between the clinical side, the administrative side, and the IT side of healthcare.

As a multilingual person who grew up in a multicultural household, I learned a lot about interpreting :

  • How culture, context, and language all interplay and influence each other.
  • How hard it is to pin down which of the three is more influential in communicating a message.
  • How language is sometimes unable to convey a specific message. (* - IMHO, this is why art, poetry, and music exist - To help send those messages where language fails.)

So I feel like a lot of my the CMIO role is like being a United Nations Interpreter - I have to consider the culture, context, and language that each member of a team is using, and try to make sure that the "same message" is being received at the other end of the line.

I can only say that quietly, I see a lot of confusion happening in the national healthcare discussion because we don't appreciate the linguistic issues which contribute to that confusion. We don't see it because we're all speaking English... right?

To give an example of what I'm talking about, I sometimes act as an interpreter between the German and American members of my family. This is a fairly straightforward act, where :
  • At dinner, one of my German family members will say something in German.
  • I listen to what they said, and have to consider both the context of the message, and the German cultural perspective of what they said
  • I have to mentally prepare a translation with a similar theme in English with an American perspective.
  • I have to help verify the context and quality of my mental translation by comparing it with a similar American cultural context (if one exists). 
  • Sometimes, despite your best efforts, there is no way to do this 100% effectively - This is why there are words that 'cannot really be translated', like "Kindergarten" and "schadenfreude" which make their way into the English/American lexicon.
  • I deliver the best English translation I can that, hopefully, is as close to the content, context, and spirit of the original message.
This process of translation is fairly intuitive to most people when speaking different languages because, well, they are different languages - There is virtually no way my American family and German family can talk to each other without an interpreter.

The problem in many healthcare discussions is that we're all speaking English - So the context and cultural perspectives of different members of the healthcare workforce are not as apparent, and so it's not as immediately clear that you've crossed cultural boundaries. In short - It's very easy for messages to get mixed up because people aren't always aware when they have crossed a cultural boundary. People may have experienced this in any business, but healthcare is particularly susceptible to this due to the many cultures that interplay in healthcare - Clinical, administrative, technical, business, etc.

As a CMIO who grew up multilingual, however, I'm keenly watching for those cultural boundaries, and playing so many roles, I try to act as an interpreter and watch to make sure the right message was received on both sides of the fence.

Still, even with my experience, I was recently humbled when I inadvertently crossed a culture boundary  - I tried to let a family member know I moved their mother to the ICU just as a precaution :
Me : "I moved your mother from the floor to the ICU just as a precaution."
Family : "What was my mother doing on the floor? Did she trip and fall?" 
(Same word, different culture and context - Good thing this person asked for clarification! What if the family hadn't asked for clarification?)

An interesting parallel to this discussion - UN interpreters are generally expected to study both of their languages equally well and to live in both cultures, so they understand the cultural context, jargon, slang, and idiomatic expressions in both languages. In the same way, I think that's why it's helpful for me to work both clinically and administratively - It helps me understand the language, jargon, slang, and idiomatic expressions of both cultures.

So Mark, as a multicultural, multinational, and multilingual guy himself, totally understood this issue and wrote this really interesting blog post where he spoke about an experience he had while visiting South Korea, when he participated in a 'translational daisy chain' where a diverse group of visitors were trying to help a French-speaking Belgian woman buy tickets. Using a combination of people, all bilingual but speaking different languages, they established a French <> English <> German <> Korean translation chain, and by each person working on their part of the translation, this French-speaking woman was able to buy tickets from a Korean-speaking vendor.

It's one of the craziest stories I've ever heard, but it beautifully demonstrates both the value of bilingualism and the work it takes to get even a simple message across four languages and four cultures. Anyone who has played the game "Telephone" just using English knows how easy it is to fail to relay a message - Imagine doing it across four languages and cultures!

I suppose this might be one of the reasons I see a lot of CMIOs from diverse backgrounds, where something about their life experience taught them to be comfortable crossing cultural boundaries and 'seeing both sides of the coin'. This seems to be a fairly common trait among the other CMIOs I meet. For me, it's part of the reason why I so enjoy helping to further define and clarify the CMIO role - to help healthcare evolve and adapt.

Remember, this is just academic banter, and your mileage may vary. Always enjoy comments, questions, thoughts, and discussion!

Friday, March 23, 2012

Improving organizational Informatics by leveraging your Intranet

1. THE PROBLEM
A common problem with EMR and EHR implementation in a hospital is usually : How do we get enough Informatics staff?

You need the Informatics talent to help with the initial implementation. You need them later to help with the maintenance and training. You need them to help with "special new clinical projects" which require engineering many tools to a higher standard than you did in the paper world. You need them to help achieve Meaningful Use. You need them to help ensure the steady flow of good clinical data to quality management. You need them for expert advice on workflow redesign and systems issues.

The problem is that many hospitals don't have as much Informatics support as they'd like. Why?
  • Informatics is commonly confused with IT, making for difficult budgeting decisions when trying to build an Informatics platform.
  • The term "Informatics" is used so loosely, many people just don't really know what they're looking for.
  • Even if you know what you need, and have the budget - There are not a lot of well-trained, experienced Informaticists around!
So if you're a lonely Informaticist in a large organization, you might be facing the challenge of : How do I help everyone in our organization to achieve their dreams and accomplish their goals, when it's just me?

Often the stretch on Informatics resources makes it almost impossible to help everyone achieve the workflow clarity they need.

So it's not uncommon that Informaticists start to fantasize, "What if I could teach people in every department some basic Informatics so they could manage their own projects that will work with our EMR?" You're never going to get them all to take the AMIA 10x10 class, but what if you could get them to start thinking differently about their tools so they could engineer them better BEFORE they approach your Informaticists and Clinical IT Analysts?

2. THE PLANNED SOLUTION
There's a little tool most hospitals have, that can help you bring clarity to virtually everyone in your hospital - It's your Intranet. Yep, that page that comes up every time you open a web browser - Is it helping your organization as much as it can? Are you using it to publish your important documents internally?

Some signs that your Intranet needs some updating include :
  • You don't really look at it much.
  • You only use it to get to Up-to-Date, or to the phone paging system.
  • You have trouble finding what you're looking for.
  • It's very lengthy.
  • You set your home page to Google rather than your Intranet.
Remember - This is the one place virtually every person in your organization starts off with - Why isn't it helping them more? 

The challenge, of course, is to make it as chock-full of deliciousness as you can. Cut out the waste, and only include the good stuff. And not just for the docs, or the nurses, but for *everyone* - Administrators, pharmacists, respiratory therapists, etc...

So after developing the CMIO's checklist, it dawned upon me that one could leverage their Intranet home page in a way that would :
  • Bring clarity about the documents your organization manages.
  • Bring all of the documents "close" to that home page in an organized, methodical way.
  • Give a little "drop" of Informatics education at every click.
  • Create real ownership of all of your important documents.
  • Creates real organizational transparency for those documents you want to be transparent.
  • Create linguistic harmony in your organization (to help meetings run more efficiently)
  • Facilitate supervision of your employees and committees
So by putting apples-with-apples and oranges-with-oranges, you can use the definitions from your organization's CMIO's checklist in a way that puts virtually every piece of paper within (I estimate) five clicks of that Intranet home page. Here's what it hypothetically could look like :

DRAFT - MAIN INTRANET PAGE
--------------------------------------------------------------------------------

  1. Telephone Numbers - Tools to contact a person
  2. Emails, Screen Savers, and Posters - Tools to help send a short message
  3. Schedules - Tools to show who is responsible at what date/time
  4. Policies and Procedures - Tools to learn organizational standards and how to achieve them
  5. Guidelines - Tools to help educate and guide staff towards a desirable outcome
  6. Documentation - Tools to record and transmit information
  7. Orders - Tools to document and transmit instructions to deliver care
  8. Order Sets - Tools to standardize and expedite the ordering process for a common scenario
  9. Clinical Protocols - Tools to standardize and automate a clinical process
  10. Clinical Pathways - Tools to standardize daily care for a diagnosis
  11. Education Modules - Tools to help educate patients/staff
  12. Dashboards and Reports - Tools to help you monitor something
  13. Templates - Tools to help make a document
  14. Wikis - Tools to help organize information/links for  a department
  15. Committee Charters - Tools to assign committee duties and responsibilities
  16. Committee Minutes - Tools to record committee activities
  17. Glossary of Terms - Tools to learn organizational definitions for common terms
--------------------------------------------------------------------------------
    Need to add something to this page? Call Dirk Stanley at 555-1212 or email him at dirkstanley@_____.com.

    First, you'll notice at the end I have a link about "add something to this page" - That's your cue to bring a user to the documentation they need to understand when making/drafting one of the tools. It's not too hard to write a page or two on "how to write a protocol" or "how to write a policy" - This puts that documentation in their hands, easily-found, in the same-place-everytime, and empowers them to help organize their projects before they approach the Informaticist.

    Next, you'll notice there is less clutter. It keeps your Intranet home page tidy and makes every link meaningful. Aesthetically it's pleasing, even as text. Could look even better with some good graphics design.

    It also fits nicely into a Drupal-style framework - Flexible, easy-for-departments-to-maintain, and your organization's history is well-documented.

    Finally - if you keep this same sort of format throughout your entire Intranet, then I predict :
    • Users will learn about the tools and their definitions every time they look for a document
    • Users will learn that "it's more than just order sets" that are involved in clinical changes
    • You will make it very easy to link these electronic documents to your EMR for various purposes (e.g. reports, protocols, etc.)
    • Virtually every important document will end up about 5 clicks from the home page
    • Users will find the Intranet a high-value site
    • It won't just be the clinical side that "goes electronic"
    • Your Intranet Home Page will become a tool and a resource for everyone in your organization.
    I haven't fully implemented this framework myself, yet - Make no mistake, achieving this level of efficiency on your Intranet is no small task, and will likely require an entire team and a lot of buy-in from your organization. But it's the conceptual framework I am working on - Tight, efficient, smooth information flows that bring employees together in one place, rather than allowing technology to separate them.

    Remember, your mileage (and definitions) may vary! Would love to know if any readers have achieved this level of informational efficiency. How did it go? What were the setbacks and successes you had along the way? We're all both teachers and students, so I always welcome comments! 

    Wednesday, February 22, 2012

    Rethinking #Healthcare management with #SimHospital

    So I'm at the HIMSS12 conference in Las Vegas this week, where it's been very inspiring - Meeting lots of #HealthIT and #Informatics people with whom I share a lot of the same passions and thoughts. Breakfast started with Eric Dishman (@ericdishman) of Intel talking about "Big Data", the greying of the world population driving the need for technology solutions to healthcare and importance of disruptive innovation. Biz Stone (@biz) of Twitter opened up the keynote today, talking about opening up information flows and the modern information revolution. The common theme at this conference seems to be : A need for disruptive innovation to help drive development of a more efficient, more personalized, and more distributed healthcare model.

    For example, yesterday at the #CMIO forum, after listening to all of us share stories, it became clear that two of the important roles of a #CMIO are to be a thought leader and to be a cautious steward of disruptive innovation that really helps patients

    Of course, since I'm passionate about creating #Informatics platforms and well-designed tools that clinicians and administrators can use to work together, I thought : Could I look a step higher, and develop something that helps more than just the clinicians? Could we make something that helps healthcare efficiency on a national level?

    And so for inspiration, I turned to a common theme in engineering and development : The three worlds of development.

    A. THE THREE WORLDS
    Engineers and software engineers are very familiar with this concept - Clinicians, administrators, and politicians generally aren't. 

    One of the fundamental tenets of good Informatics is understanding the way ideas come to fruition in a safe and organized way - By moving an idea through three different stages of organized development :
    1. The DEVELOPMENT stage
    2. The TESTING stage
    3. The LIVE (sometimes called "PRODUCTION") stage
    Huh? What does this mean, exactly? 

    To help develop things in a safe, controlled, and predictable way, most engineers think long and hard about:
    1. How can I DEVELOP an idea safely?
    2. How can I TEST an idea safely?
    3. How can I make something go LIVE safely?
    And so, most engineers and informaticists are familiar with these three different worlds and how to use them : 
    1. "DEV" - (the "development" world) - Typically, used by people who help build/develop the idea
    2. "TEST" - (the "testing" world) - Typically used by those end-users who test the idea
    3. "PROD" - (the "live" world) - Typically used in real-life by those people who actually use the idea
    So if you train your brain to think about these different stages of organized, controlled development, you will actually be better at developing things in an organized and predictable way.

    The funny thing is that often these three worlds are used by engineers and Informaticists, but the rules actually apply to many, many other things we develop in real life, whether we realize it or not. For example, many people live in a house :
    1. "DEVELOPMENT PHASE" of House : Point where builder is building the house according to specifications
    2. "TESTING PHASE" of House : Point where safety inspector looks at house design and tests for adequate safety
    3. "PRODUCTION/LIVE PHASE" of House : Point where person moves into house
    Or you might send an email :
    1. "DEVELOPMENT PHASE" - Point where you are writing and drafting the email
    2. "TESTING PHASE" - Point where you are proof-reading the email and checking the spelling
    3. "PRODUCTION/LIVE PHASE" - Point where you click "SEND" and make the email a reality
    Or you might send a paper letter to someone :
    1. "DEVELOPMENT PHASE" - Point where you are writing and drafting the mail
    2. "TESTING PHASE" - Point where you proof-read the letter before putting it in the envelope
    3. "PRODUCTION/LIVE PHASE" - Point where you drop the letter in the mail to make it a reality
    So I usually recommend to new Informaticists that they should become familiar with these three worlds, and :
    1. Who uses which world for what?
    2. What process will you use to transfer ideas from one world to the other?
    It's also why I personally feel that some older healthcare change concepts like 'Test of Change' are kind of outdated - They only encourage crossing over from one world to the other without a formal process. 

    Again, a good Informaticist understands these three worlds, how to use them, and helps an organization define the standards by which tools will be moved through these three stages of development. Generally, with regards to Health IT development :
    1. Software engineers/analysts live in the "DEV" world (often with help of an Informaticist)
    2. Owners/End Users live in the "TEST" world (often with the help of an Informaticist), and 
    3. Real-life people live in the "LIVE" world.
    B. THE CONCEPT : SimHospital

    So to help HIMSS and the ONC drive some really innovative thinking about bending the healthcare cost curve, I wondered - Could we actually use these common engineering/informatics principles to help more than just software engineers and informaticists? In other words, could we use these principles to help patients, administrators, clinicians, and politicians understand healthcare better? How would we do that? 

    So it dawned upon me, a great tool that could help improve healthcare management and delivery would be a robust TESTING GROUND for healthcare change. Enter the idea : SimHospital.

    SimHospital would be a computer-modeled, virtual hospital where all of the basic characters in healthcare could live in a safe, virtual environment that allows for testing. Just like the popular  SecondLife world or TheSims series, it would be a virtual hospital with virtual-reality avatars that are built to behave much like their real-life counterparts - E.g. virtual patients, doctors, nurses, pharmacists, respiratory therapists, couriers, and other hospital staff could all be designed to behave in fairly predictable manner, based on certain variables like :
    1. Education/training
    2. Allowed tasks
    3. Predicted compliance with tasks
    4. Clinical tools and communication to facilitate interactions between team members
    5. Contracts and Policies to guide behaviors
    And I think in this virtual, simulated world, we could allow better testing of ideas like :
    1. How will changing a policy or regulation impact care?
    2. How will changing a clinical or administrative tool impact care?
    3. How will changing a workflow impact resources?
    4. How will adding/removing a department impact workflows?
    This virtual world would also be an amazing training tool for clinicians, administrators, and politicians - If we commonly ask pilots to train hours in a flight simulator, maybe this SimHospital could be used to train healthcare leaders to understand their environments better.

    It could also, if developed, be used as a tool to help do predictive modeling for healthcare outcomes - If the ACO movement is going to make organizations responsible for both the delivery and outcomes of healthcare, then SimHospital could be a very useful tool to predict the outcomes of a particular intervention.

    And if we wanted to expand beyond the boundaries of the hospital, we could also develop SimHealthcare to model the hospital and outside PCPs and specialists, again, to help predict how a change in one or more variables will probably lead to what results.

    I think it could be a pleasantly disruptive way of improving education for healthcare leaders and simultaneously help with the predictive modeling that will be required for ACOs to succeed. 

    As with many of my posts, I'd like to throw the idea out there, and would be interested in hearing comments. (Do I have any readership from SecondLife or TheSims programmers who want to use their skills to help reform healthcare?) :)

    Remember : This blog is for education/discussion and brainstorming only. Your mileage may vary. Always interested in hearing your thoughts and comments!

    Sunday, February 5, 2012

    Could a new note, the Football, help improve healthcare?

    As I've mentioned in previous posts, the American government cannot set up a national patient identifier. So projects like NHIN Direct generally rely on a document push mechanism which, essentially, allows one healthcare provider to push an authorized, HIPAA-secure document to another healthcare provider.

    I'll admit it - I wish we could have pull.

    The reason I want pull? A centralized, patient-centric medical record (like in the #SpeakFlower model) would make it much easier for various providers to pull and update information in a virtually central location. Pushing documents is going to have its workflow challenges, and leave some with the question, "Where is the patient's real chart?".

    So since I recently became involved in our Massachusetts discussion on Health Information Exchange, I'm struggling with the question of how to implement a state-wide HIE system that will allow providers, at least initially, to push documents to eachother.

    So my first informatics question, on being given this challenge, is : What will people push? Who will push it? And to whom? And when?

    To try to answer these questions, I invited folks to our last Interstate 91 Informatics dinner in January to discuss "Can we do better than SOAP?" by asking everyone :

    1. What documentation do people want?
    2. Could we develop any group standard templates for standardized documentation, to save us all development costs?
    3. Could we develop any rudimentary, area-wide clinical governance so we can share documentation easier, and thus all benefit from a common language?
    4. Ultimately, who will push what documentation to whom, and when?

    And after a rousing discussion, the answer I heard was this : Everyone has a different opinion.

    I guess it's entirely understandable... ICU docs, PCPs, surgeons, specialists, hospitalists, and everyone else has a common goal - making the patient healthier - but they have different training and thus they all have different needs. This is why when I hear docs say "I just need the important information!", I smile because ultimately, all of the information in a chart is important - It just depends on your context and clinical needs.

    So I'm left with the ultimate Informatics challenge - How can we get the right information to the right person in the right place in the right time in the right way? Especially when everyone has a different opinion on what the right information is?

    And is there any way we can develop a standard lingua franca that all doctors speak?

    Is there something that all docs would know how/when to use, in a standard way?

    THE CHALLENGE

    So to better understand the challenge here, I looked to the most common issues I hear doctors, nurses, and administrators talking about :

    1. Med Reconciliation (at virtually every stage of care)
    2. Handoffs inside a hospital
    3. PCPs wanting notification that their patient has been admitted
    4. PCPs wanting discharge summaries when their patients are discharged
    5. Quality
    6. Waiting times
    And given the push mechanism it looks like we are going to get, at least initially, how are we going to set any standards?

    There is one thing issues #1-6 above share : They are mostly all caused by the lack of a common, portable, #SpeakFlower-type, patient-centered chart, which we currently lack in modern private healthcare. (Note : I say private healthcare because the Veteran's Administration/VA VistA system actually has a pretty seamless, continuous, portable patient chart that only works inside the VA system for various political and cultural reasons...) 

    But in a private, push world, is there any way we could we start to approach some kind of a portable, patient-centered chart?

    In other words, is there any way we could leverage our push system in a way that actually simulates a patient-centered chart?

    And how would we implement this?

    THE CURRENT STATE

    Looking at the current buffet table of documentation, it's no wonder that every doctor has a differrent opinion of what they need. There aren't really any hard standards for clinical documentation. As I've mentioned in previous posts, most doctors learn about documentation from things like the Washington Manual Internship Survival Guide. So as a result, most physicians are familiar with things like :
    1. Admission H&P
    2. Progress Note
    3. Discharge Summary
    4. Transfer Note
    5. Encounter Note
    6. Procedure Note
    7. Visit Note
    8. Consult Note
    And so when our Interstate 91 Informatics group got together, it's no wonder every doctor had a different opinion of which note they would want to get, and when.

    So to look for inspiration on how to build a standardized document that every doctor would know how to use, and when to push to whom, again I thought : Could we make a standardized push document that approaches the portable, patient-centered chart we all want?

    THE INSPIRATION
    It dawned upon me that to solve this problem, we will need a new type of note. And so if it's something that's not in the Washington Manual Internship Survival Guide, it would have to be something that was so useful, so intuitive, and so desirable - like McDonalds French Fries - that every doctor would *want* to use this note, update it, and push it to the right person at the right time.

    So then I thought - We are really asking for a portable, mini-chart that we can push around to the next provider.

    And then I wondered, "What will we name it?" The "Mini-chart"? The "Patient Summary"?

    What we're really talking about here is a "Patient Handoff Note" - The 'mini-chart' - And to make it extra-intuitive, I've decided to nickname it "The Football".

    (Interestingly - "The Football" is also the nickname given to the "Nuclear Football" which the President of the United States carries around at all times, which according to Wikipedia is designed to be "a mobile hub in the strategic defense system of the United States" - A portable, role-centric tool for making important decisions... Huh! Talk about portable documentation!)

    Also by nicknaming it "The Football", it gives users a visual clue about how to use it and when to punt it to the next physician.

    THE PATIENT HANDOFF NOTE ("FOOTBALL")
    The Patient Handoff Note ("Football") is basically a patient mini-chart, designed to be used in handing off care from one physician to another. In other words, physicians could think of the Patient Handoff Note ("Football") as a document that they update and push to the next physician expected to see the patient.

    Who is the next physician expected to see the patient? Whoever is expected to see or cover the patient next. If you're a PCP expecting a specialist to see your patient, you'll update the football and send it to the specialist. If you're a specialist done with the consult, expecting the PCP to see the patient next, you'll update the football and send it back with the patient to the PCP

    Of course, the key word here is expected - What if a patient has an unexpected trip to the ED?

    I thought the note should be of such high value that, on arrival, the ED physicians would request the Football from the PCP. (By doing this, they would ensure the PCP knew about the visit.) And when the ED doc decides to admit the patient to the Hospitalist, they would update the football and push the patient and football to the expected Hospitalist.

    And the admitting hospitalist could update and push the football to the expected hospitalist the next day. 

    And the daytime hospitalist could update the football and push it to the expected overnight covering staff. 

    And the overnight covering staff, if needed, could update the football and push it to the daytime hospitalist.

    And the daytime hospitalist, on discharging the patient, could update the football and push the patient and football back to the PCP.

    (To the patients reading this, I apologize - This is really referring to document management, not patients - I am definitely not endorsing pushing patients around!) :)

    So anyway, back to the football - what could this Patient Handoff Note ("Football") look like?

    Here's my first draft - As an example, I'll show how it could be used at the point of discharge :

    [ DRAFT ] PATIENT HANDOFF NOTE ("FOOTBALL")
    PATIENT NAME   :   VADER, DARTH A.
    DATE OF BIRTH   :   Jun 06 1966

    Emergency Contact :
    Tarkin, Emperor
    Relationship : Father
    Cell (914) 555-1212

    CODE STATUS : 
    Full Code (last verified by Luke Skywalker, MD, PCP, Internal Medicine, Oct 30 2009)

    DATE OF HANDOFF :
    Feb 03 2012

    HANDOFF FROM :
    Dirk Stanley, MD (Hospitalist, Internal Medicine)

    EXPECTED HANDOFF TO :
    (   ) Overnight Coverage 
    (X) Other : Luke Skywalker, MD (PCP, Internal Medicine)

    AUTHOR : (Note : This is who is pushing the football today)
    1. Feb 03 2012 - Dirk Stanley, MD (Hospitalist, Internal Medicine)

    CO-AUTHORS : (Note : this is essentially everyone who has pushed the football in the past, with last date they pushed it, in reverse date order)
    2. Jan 28 2012 - Han Solo, MD              (Attending, Emergency Medicine)
    3. Sep 22 2005 - Beru Whitesun, MD    (Attending, Gastroenterology)
    4. Apr 02 2004 - Luke Skywalker, MD (PCP, Internal Medicine)
    5. Apr 01 2002 - Ben Kenobi, MD        (PGY-1, Internal Medicine)
    6. Feb 22 2002 - Owen Lars, MD         (Attending, General Surgery)
    7. Jan 11 1996 - Leia Organa, MD        (Attending, Cardiology)

    ALLERGIES :
    1. Mar 29 2002 - Bactrim (Rash/Hives)

    PMHx/PSurgHx : (Note : This has all problems/history identified in reverse date order)
    1. Feb 03 2012 - Aspiration Pneumonia
    2. Feb 25 2002 - Cholecystitis, s/p cholecystectomy
    3. Sep 22 2005 - Colonoscopy, s/p benign polyp removal
    4. Jan 11 1996 - CAD s/p NSTEMI, no catheterization, medical management
    5. Oct 12 1994 - Hyperlipidemia
    6. Apr 03 1992 - HTN

    SIGNIFICANT STUDIES : (Note : This is noted by docs, again in reverse date order)
    1. Jan 28 2012 - 2-view Chest X-ray = (R)LL patchy infiltrate
    2. Jan 04 2004 - PSA=0.06

    WHAT I DID :
    Patient admitted to Mos Eisley Hospital on 1/28 with cough, fever, purulent sputum approx 3d after being found asleep and intoxicated at a party. Chest X-ray showed (R)LL infiltrate, WBC=21k, PMNs=80%. Started Zosyn IV and after 3d patient improved. Changed to oral Augmentin on 2/2/2012. Now ready for discharge today 2/3/2012.

    ACTIVE MEDS (AT TIME OF HANDOFF) :
    1. Lisinopril 5mg PO daily
    2. ASA 81mg PO daily
    3. Metoprolol 25mg PO 2x/daily
    4. Simvastatin 40mg PO daily
    5. Augmentin 875mg PO 2x/day x7d, to complete on Feb 09 2012

    TO-DO LIST :
    1. Feb 15 2012 - PCP to follow-up with patient for routine follow-up visit
    2. Mar 01 2012 - PCP to repeat Chest X-ray to ensure resolution of pneumonia
    3. Apr 01 2012 - PCP to repeat lipid panel and LFTs to monitor Simvastatin dose
    4. Apr      2015 - Gastroenterologist to repeat colonoscopy to follow-up benign polyps 
    5. Jan       2020 - PCP to give repeat Tetanus vaccination 

    SIGNED : __Dirk Stanley, MD_(Hospitalist, Internal Medicine)______ Date : Feb 03, 2012     
                                         
    (My apologies to George Lucas - I'm obviously a big fan - Hope you don't mind me using characters to demonstrate this new medical note...!)

    Anyway, I think the advantages of this drafted Patient Handoff Note ("Football") are this :
    1. It would be a very high-value note that docs would look and ask for (like McDonalds French Fries!) when receiving a patient :)
    2. After receiving the football from another physician, it makes creating your local documentation much easier.
    3. After receiving the football from another physician, it makes it very easy for you to update the football for the next provider.
    4. By making it something all doctors expected, it would drive ownership of the note by all physicians, so...
    5. ... It encourages docs to own, review, and continuously update the full med list, problem list, to-do list, allergy list, etc
    6. It makes med reconciliation easier for everyone.
    7. It could virtually replace notes involved in the expected transfer of care such as the transfer note, overnight coverage signout, discharge note, and consult referral
    8. Nicknaming it "The Football" makes it fairly intuitive about its importance and who to push it to and when
    9. In a push environment, in an unexpected transfer of care, an ED doc or Hospitalist requesting this from the PCP would pretty much ensure the PCP was notified about the admission in a timely basis.
    It's definitely an off-of-the-beaten-path idea, but I'm going to suggest it to my fellow physicians here in Massachusetts, as we start to warm up our state-wide HIE and get it running. Will let you know the results!

    Is this note wishful thinking, or just crazy? Always interested in feedback and questions! Send me your thoughts and ideas! Love the discussion just for education's sake!