Top 15 Signs You May Work in Clinical Informatics

Hi fellow CMIOs, CNIOs, Clinical Informaticists, Clinical Informaticians, and other #workflow and #HealthIT friends,

Over the last 10 years, I've blogged a lot about different topics in applied Clinical Informatics, from change management to glossary development and workflow terminology management, to order set development. And yet, across the industry, it can sometimes be a challenge to find the other people who do this type of work, partly because: 

• There are some people who 'do Clinical Informatics work', but are not labeled Clinical Informaticists / Clinical Informaticians in their job title. (Some are labeled CMIOs, CNIOs, Directors of Clinical Informatics, Clinical IT Analysts, Business Analysts, etc.)
• There are some people who do have a job title like 'Clinical Informaticist/Clinical Informatician', but focus their efforts mostly on a particular branch of Informatics, without clear support for the other branches (often due to resource limitations).
• Some 'Clinical Informatics' people focus their work for only their clinical specialty (e.g. 'Physician Informaticist', 'Nurse Informaticist', etc.)

So since in some regions, applied Clinical Informatics in 2020 still seems to be an emerging field, one that is fortunately becoming more formal and structured with the advance of more formal training and certification programs - I decided to spontaneously write a humorous piece on Twitter that could appeal to the 'Clinical Informaticist' (or 'Clinical Informatician') in all of us : 

Feel free to share with any Clinical Informaticists (or Clinical Informaticians) you know with a sense of humor! :)

Remember, this blog is for education and discussion purposes only - Your mileage may vary. Have any helpful humor or insights about Clinical Informatics, job titles, and professional development? Feel free to leave them in the comments box below!

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!

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.
• A 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!