Wednesday, February 10, 2016

Should Clinical Informaticists be licensed?

Hi readers,

I was recently talking with a group of informatics professionals about the issue of clunky workflow and 'click burden', which is a constant issue in EMR adoption. The conversation raised a question I've been wondering about recently - Should Clinical Informaticists be licensed? To help answer this question, I thought it would be fun to take a trip back in time and see if history can help guide us. 
Our trip back started recently when I was reading about the history of the area where I live - Northampton, MA, which sits in western Massachusetts, at the foothills of the Berkshire mountains, along the Connecticut River. I was really surprised to learn about the history of a little stream that runs along Route 9, the Mill River - Which in 1874 was the site of a horrible tragedy, which eventually helped contribute to advancements in safety and engineering that we benefit from today.

To start our journey, I'd like to thank Elizabeth M. Sharpe, PhD, the author of this great reference that nicely summarizes the events : https://pvhn3.wordpress.com/1800s/mill-river-flood-of-1874/ 

In short - The Pioneer Valley, as it's known, was once the site of great industrial strength, like many New England towns. Buttons, cloth, brushes, and paper were all produced by factories in this area, and shipped off for sale to other places via a rail system that used to connect the area with other parts of the country. 

And like many industrial areas prior to widespread electricity, these factories depended on waterways for energy. The Mill River, about 15 miles long, was one of those waterways.

So back in the 1870s, a group of local factory owners, disappointed with their inability to produce goods during prolonged droughts, developed an idea : To build a big reservoir up in the hills, in a little nearby town called Goshen - So if there was a drought, the idea was, the water could be let out into the Mill River, and the factories could stay in business.

So the factories commissioned the building of a big, 100-acre reservoir up in the Goshen hills. From the Dr. Sharpe's site https://pvhn3.wordpress.com/1800s/mill-river-flood-of-1874/  : 
"In the absence of state regulation on dam construction, the reservoir company was free to design and build the dam as they pleased.  Frustrated with the $100,000 cost of a design prepared by professional civil engineers, the company opted to dictate their own design to an incautious local engineer who wrote general specifications.  The company then hired careless contractors for $24,000 who made the inadequate design worse.  Despite repairs, the dam leaked and slumped for eight years.  Anxious valley residents who questioned the dam’s safety were reassured by the manufacturers that the dam would hold.
Sure enough, on May 16th, 1874, the weather had been unusually rainy, and the dam gave way. Millions of gallons of water suddenly spilled down the Mill River, sweeping houses, barns, bridges, roads, factories, and people, and down the river, killing 139 and making over 700 people homeless. The New York Times took two days to figure out what happened (before the telephone), but eventually reported this : 
(NYTimes, May 16, 1874)"ACCOUNTS FROM SPECIAL CORRESPONDENTS.""THE CONSTRUCTION OF THE DESTROYED DAM - THE RUSH OF THE FLOOD DOWN THE VALLEY - THE VILLAGES DESTROYED. PARTIAL LIST OF THE DEAD. MORE BODIES FOUND. PROBABLE LOSS BY THE FLOOD.""Northampton, Mass., May 16. - The beautiful valley of the Connecticut River was laid waste to-day, and five villages totally destroyed. The heavy rain of Friday night and this morning caused a rapid rise in Mill River, on the banks of which were built the villages of Williamsburg, Skinnerville, Haydenville..."
What strikes me most about the story came from the hearings following the disaster : 
"A coroner’s inquest thoroughly investigated the disaster’s cause.  The verdict named five parties at fault: the reservoir company which owned the dam; the contractors who built it; the engineer who provided an inadequate design; the county commissioners who inspected and approved it; and the Massachusetts legislature which chartered the reservoir company without requiring any assurance that it was safe.  There were no indictments, no fines, and no subsequent law suits.  A year after the flood, in 1875, Massachusetts passed its first legislation regarding reservoir dam design, construction, and liability.  Considered weak by today’s standards, the law was, nevertheless, a first step toward safer dams."
And so, through disasters like this (and the similar Johnstown Flood of 1889), eventually America came to learn that all engineers actually needed to be licensed. See the National Society of Professional Engineers page commemorating this achievement here :  http://www.nspe.org/resources/press-room/resources/100-years-engineering-licensure 

As a result, today, the houses we live in, the elevators and cars we ride, and the water we drink has all been designed by a trained and licensed engineer, whose responsibility it was to ensure the successful design and safety of the project.

And so the house, car, and elevator you got into all followed basic engineering principles and started as blueprints, which were tested before they were built, inspected, and approved for use.

Historically, healthcare did not apply these engineering principles to workflow development. Generally, doctors and nurses built these workflows organically, through informal agreements about how to take care of patients made over many years - Typically with no blueprints, no project plans, and no formal approval process. But with the advent of modern EMRs and ACOs, we now need to engineer workflows to a higher standard. 

This brings us to the question of licensing Informaticists. Despite the significant efforts of AMIA, ANIA, and HIMSS to formalize and standardize the role, there still are still a number of "Informaticists” who have no real training on CDS or clinical workflow design. Similarly, there are some people doing CDS and clinical workflow design with no formal Informatics training, or even recognition that they are working as Informaticists (because they have other job titles like “Clinical Knowledge Expert” or “Solutions Engineer”) - 

While certificates, degrees, and board certification in Informatics goes a long way in improving the quality of workflow design, healthcare still has a long way to go in recognizing the importance of this certification, and why it's important to have trained, certified engineers (Informaticists) designing the orders, order sets, protocols, documentation, and workflows in the EMR, to help streamline clinical workflows and reduce click burden.

So the Mill River teaches us that it's better to have a dam built by a trained, licensed engineer, with legal responsibility for the outcome, than to have one built by an “engineer” with no formal training. And this is why organizations seeking to improve click burden and streamline their workflows might be well-served to have trained, certified Informaticists leading their EMR configuration. And to help achieve this primary goal, it's helpful to call Clinical Informaticists what they really are - Clinical Informaticists.

I hope this post has been a fun trip back in history, and helpful to you in developing your own Informatics platform.

Remember these posts are for open discussion and educational purposes! Have any thoughts or feedback? Leave them in the comments section below!

Wednesday, February 3, 2016

The Red Sneaker Problem - And how to fix it

Hi fellow Informaticists, chairpersons, and other budding healthcare leaders!

There's no question - Healthcare is currently under tremendous pressure to perform. Quality needs to go up, at the same time that costs go down - And fast. In my own humble opinion, it's currently undergoing change at a pace that's hasn't been seen since the inventions of penicillin and vaccinations. 

Informaticists know that information drives behaviors, and the information doesn't just start-and-stop inside the clinical arena. To really drive down the cost of healthcare, we need to work on efficiency at all levels of healthcare

So there is a quiet little information problem I sometimes see, that I thought I'd share in today's post, to help you spot it and fix it. I call it the "Red Sneaker" problem.

The Red Sneaker problem sometimes happens, quietly, when a well-intentioned committee, with a well-intentioned chairperson, makes a well-informed decision.

Typically, it starts with someone in an organization learning about some new regulation, or evidence of a way to make things better : "The evidence clearly shows that patients like Red Sneakers, and they heal faster when staff wear Red Sneakers - So if we all wear Red Sneakers, costs will go down, quality will go up, and patient satisfaction will improve."

After bringing the idea to a committee who asks for a few presentations and data on the potential benefits of Red Sneakers, the committee finally votes on the question : "Should all staff wear Red Sneakers?". After some deliberation, the committee votes, and the motion is adopted : All staff will wear Red SneakersThe committee celebrates the victory, and the secretary documents the vote in the committee minutesPeople leave the committee meeting, and through emails and word-of-mouth, other people learn that the committee has voted to approve Red Sneakers for all staff.

The quiet problem that sometimes arises is that the committee was not well-positioned for success. The chairperson is new, and might not understand the parliament or committee position in the governance of the organization. The members may not be clear about the mission of the committee. The committee was not made aware of its responsibilities, authorities, or jurisdiction. And so, the vote was overwhelmingly in favor of all staff wearing Red Sneakers, but...
  1. No policy was updated to reflect the new organizational standard of all staff needing to wear Red Sneakers.
  2. No budgets were updated to pay for the ongoing use of Red Sneakers.
  3. No local suppliers were contacted to establish the availability of Red Sneakers.
  4. No employment contracts were updated to require the wearing of Red Sneakers.
  5. No staff education was created for staff to understand the new standard and importance of wearing Red Sneakers.
  6. No onboarding materials were updated to teach new staff about the importance of wearing Red Sneakers.
  7. No workflows were designed to check for Red Sneakers before staff enter the organization
  8. No backup procedures were created for staff who arrive without Red Sneakers.
Without any of this background work, the committee still announces the result of their vote, and record it in the committee minutes. Initially, things look good. With enough cheerleading and word-of-mouth publicity, they start to see some adoption of Red Sneakers


But without planning for these other reinforcements, Red sneakers were not well-budgeted for. Eventually new staff will come into the organization who don't know about this committee vote, and missed the publicity about Red SneakersThe few staff still looking for Red Sneakers might not be able to find them in local stores, and there are no backup procedures for staff who forget them. And with no way to support or enforce the use of Red Sneakers, after a few months, the adoption of Red Sneakers starts to dwindle...


And so the entire discussion of the committee and the vote to adopt the new measure have not been effectively implemented. Six months later, committee members notice almost nobody wears Red Sneakers, gradually get a sense that the committee is powerless, and stop showing up to meetings. Especially in healthcare, this can be an expensive way to generate frustration and apathy.

Fortunately, it's fairly easy to prevent the Red Sneaker problem. The first step is to look out for it. If you think your committee(s) might have the Red Sneaker problem, consider some of the following : 
  1. Make sure you don't have more committees than you need by ensuring that every committee has completed a yearly charter, and that all committee charters are filed in a central location in your organization, so you can look for ways to avoid overlaps and streamline your committee structure. (If you need a committee charter template to start, you can click here to read my old blog post on committee charters.)
  2. Make sure your committee chairpersons have adequate training and orientation before chairing a committee, including some training about parliament, project management, and the quiet-but-problematic red sneaker problem.
  3. Solidify your cost estimates before adopting a new measure, by making sure that committee chairs ask for detailed project plans and cost estimates before bringing a measure to a vote. These project plans should address the various tools and strategies you will use to introduce and reinforce the new workflow.
  4. Consider having a clinical informaticist, workflow expert, or other process expert to consult or help draft the project change plan and cost estimates before adopting the new measure.
I hope this post is helpful to you in developing your own informatics skills, and supporting excellence in your healthcare organization!

Have any thoughts about workflow adoption issues or clinical governance? Want to share your own stories? Leave your comments in the comments section below!