Tips and Tricks for Clinical Workflow Redesign

 Hi fellow CMIOs, CNIOs, and other Informatics friends,

Today I thought I'd share some materials I delivered in a talk back in 2023 for Dr. Judi Binderman, a really seasoned Clinical Informaticist and good friend of mine. I recently discovered these when going through some old slides. At the time, Dr. Binderman had asked me to speak briefly to her team at Community Medical Centers in Fresno, CA about some helpful tips and tricks of clinical workflow redesign : 

My talk was mostly related to workflow analysis, change management, documenting workflows, and workflow design. So I opened up first with a brief discussion about workflow analysis and change management : 

The first point that I usually emphasize for any new Clinical Informatics leaders is that work can be measured and estimated through a workflow gap analysis. The distance from the current state to the future state gives you a good estimate of the stakeholder(s) you will need to involve in a project, what they will need to learn and do (to achieve your future state), and so this gives you a good estimate of your project deliverables and project scope (for planning purposes) :

Once you have completed your gap analysis to get a sense of the current-state and future-state workflows, you can then review a list of common deliverables, to select what you will need to get your users from current to future state : 

Note that some of these deliverables (above) are inside of the Electronic Health Record (EHR), and other deliverables are outside of the EHR. You will want to identify all of the deliverables you anticipate needing/using, and then identify who you will need on your project team to help develop each deliverable.

Remember that workflow change management is a team sport - A common mistake is to think that you can make a change with 'only Doctors' or 'only Nurses'. Almost all clinical workflows depend on many stakeholders, from different enterprises, with a number of different roles. Understanding the different enterprises of your organization, and the different roles you may engage with, is helpful to make sure you've thought through all of the stakeholders you will need to make your project successful : 

Once you have a sense of the estimated stakeholders and deliverables, it's helpful to think through the steps you will need to develop your workflow. For teaching purposes, I usually shrink this down into ten (10) easy steps, that you can talk through with your development team : 

This discussion almost always brings up the debate (question?) about change / project management methodologies. Two common methodologies include : 

• Waterfall Methodology - Linear, step-by-step, good for plan-first approach, takes longer but especially well-suited for Healthcare or new high-risk scenarios where one build is all you can plan for.
• Agile (Software Development) Methodology - Iterative, emphasizes rapid feedback and adaptation, sometimes useful when clinical workflows are evolving or need user-centered design - but not ideal for Healthcare scenarios. Better built for speed and iterations.

Some people will argue that Waterfall can take too long, and they prefer the speed and flexibility of Agile. Personally, I'm not sure how well Agile fits into the many high-risk clinical workflows of Healthcare (since there is usually little room for error), and so I've condensed those ten (10) helpful steps in the slide above into this 'general-purpose change recipe' below :

Once you've gone through the exercise of writing out those ten steps, and developing your own change recipe - You can then import it into a spreadsheet, and add your common roles across the top to build out your own Responsibility Assignment (RACI) Matrix : 

This Responsibilty Assigment (RACI) Matrix can then walk you through the first step of your change management - Documentation of Request and Expectations ('Intake') - And help you to develop key questions that your requestor and their supervisor (e.g. Chief, Chair, or Director) can answer before you do further analysis.

Once you have their preliminary input and feedback, you (Clinical Informaticist) can then pursue the next steps of your journey - Analysis, scoping, prioritization, resource allocation, and project approvals - To help evaluate and develop the request, and make sure your Clinical and Administrative Leadership have the information they need to prioritize and approve the project : 

After your Administrative and Clinical Leadership understands :

• the project priority, estimated scope, estimated stakeholders, estimated deliverables, and necessary resources, 
• the estimated Total Cost of Ownership (TCO) and Return on Investment (ROI)

... they can effectively prioritize and approve the project, leading you to formal project initiation, project development, and the drafting, building, testing, approval, education, implementation, and support of your future-state workflows : 

So - What tips can I offer a new Clinical Informaticist for documenting workflows and workflow design?

My first tip is to closely examine the similarities between a 'Swimlane diagram' (Visio) and a Procedure : 

If we break down a a 'Swimlane diagram' (Visio), it basically answers the questions : 

Q : Who is doing what, and in what sequence (order)?

So with a small adaptation, we can revisit the traditional swimlane diagram as :

... which leads me to share a helpful discussion of what exactly a procedure is (adapted from Charles Webster, MD aka @wareflo, another brilliant Clinical Informatics mind I have had the fortune of learning from)

Procedure (n.) (synonym : workflow, recipe, process, algorithm) - An ordered series of tasks that uses people, time, and resources to achieve a desired goal or outcome.

Now, if you accept the definition above as true, then you can create a simple template for writing a task, the most basic building block of a procedure (synonym : workflow, recipe, process, algorithm) : 

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

where : 

• [ WHO ] = Role of the person that will perform the task
• will/may = Use "WILL" for required tasks, "MAY" for optional tasks
• [ WHAT ] = Brief description of the task
• { how } = Optional modifier, use only when needed to clarify how the task is performed
• { when } = Optional modifier, use only when needed to clarify when the task is performed (for timing/duration)
• { where } = Optional modifier, use only when needed to clarify where the task is performed
• { why } = Optional modifier, use only when needed to clarify why the task is formed

You can then include this in your own 'workflow glossary', where you define and organize your favorite high-grade (policy-grade) terminology related to workflow design : 

... but you can also use it to start writing out procedures for all sorts of things. My favorite teaching example is to take a poorly-written process (in this case, a poorly-developed process for baking and delivering cupcakes) :  

... and turn this into a well-developed process that identifies not only the necessary steps and deliverables of the workflow, but also the necessary stakeholders and their Directors/Chiefs : 

So that's a very helpful skill for the new Clinical Informaticist - Learning how to write an effective procedure. Procedures create clarity and helps you develop solutions. And this also means that your policy manual will be an excellent source of common clinical workflows, their stakeholders, and their deliverables : 

Plus, once you understand how to write a task and a procedure, you can then easily estimate the cost of the procedure by assigning either : 

• Cost = Labor + Materials
• Cost = (Salary * Time) + Materials

... to each step : 

Just for fun, you can use this trick to estimate the cost of a box of macaroni and cheese, if different clinical roles made it : 

... and so, by writing out a procedure and assigning an estimated cost to each step -  you can see the different estimated costs for an MD, an RN, a LPN, and a MA making mac and cheese :

Understanding this (and the regulatory scope-of-practice questions that naturally arise from this level of analysis) can not only help you estimate costs, but also save money, and help your clinicians to work at the top of their license - See the estimated cost of this workflow below, with an RN giving a cupcake to the patient : 

... versus the estimated cost of the workflow if an LPN gives the cupcake to the patient : 

And so, to summarize : 

And some helpful final thoughts : 

And one more final thought (wisdom once passed to me by another experienced Clinical Informaticist, early in my career) : If you're ever lost, start to untangle your workflows by writing a good procedure. 

I hope this has been a helpful journey into how to document, analyze, and develop your own clinical workflows. If you have any questions, please feel free to leave them in the feedback/comment section below! (And special thank you to both Dr. Judi Binderman and Dr. Charles Webster for their contributions to this post!)

REMEMBER : This blog is for education and discussion purposes only - Your mileage may vary. Have any other helpful tricks for quickly untangling or developing clinical workflows? Feel free to leave them in the comments section below! 

What can Cardiac Myocytes teach us about Teamwork and Workflow?

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

Today's post is short, but one that I think most clinical friends will understand and appreciate. For conceptual teaching purposes only, I'm going to ask the question : 

"Q : What can Cardiac Myocytes teach us 

about Teamwork and Workflow Design?"

Here's my theory : Clinicians may actually have an advantage here. If you've ever studied the human heart - it's anatomy, it's functions, its biology, and its electrophysiology - You already know a lot about teamwork, workflow design, clinical operations, and essentially how to get things done. 

After all, cardiac myocytes and humans (clinical leaders and team members) both work towards a common goal. We both can function as individual units, but we function even better together as a well-organized, well-synchronized team : 

[ DRAFT ] TABLE - A tongue-in-cheek but honest comparison of Myocytes with Humans (Clinicians)

Let's face it, healthcare is a team sport. So when I'm working with other clinical leaders, especially new ones - For support, I often remind them of the importance of the infrastructure and tools that, especially as clinicians, we sometimes take for granted - Good : 

• Regulations (both Federal and State)
• Governance (e.g. Committee structures)
• Leadership
• Direction
• Management
• Communication
• Bylaws
• Policies/Procedures
• Training / Onboarding
• Continuing Education
• Offboarding
• Teamwork

After all, when growing a plant - it's not just the seeds you need to worry about, it's also the soil. So without enough of this 'supporting soil' (the tools above) in place, it becomes very easy to run into problems growing the seeds - And so for end-users, managers, directors, leaders, and executives alike, this can sometimes result in loss of efficiency, frustration, disorganized workflows, problems not getting solved in a timely basis, etc.

Typically, these tools don't get enough attention from new clinical leaders, because until they are in a leadership position - their focus has largely been on 'clinical things' like working with patients, diagnosing and treating diseases, performing operations and procedures, etc. While those are all the reasons we are in healthcare, it's still important to understand the many 'non-clinical' tools that make those things happen. (In truth, those tools are just as clinical as penicillin - But due to time constraints, they usually don't teach much about them in medical schools.)

What I find especially interesting is that, as a physician who during my career has treated cardiac tachyarrhythmias at the bedside (using beta-blockers, calcium-channel blockers, adenosine, cardioversion, etc.) - There are often similar analogous ways to treat these same 'human tachyarrhythmia' problems on project teams : 

So when I have the opportunity to teach a new clinical leader about how to solve problems and function in teams, I simply remind them that modern human biology has evolved over thousands of years to solve these same sorts of problems that we experience in healthcare today - And so sometimes, looking inward with a microscope is just as helpful as looking outward with a telescope. 

Finally, one of my clinical informatics colleagues and good friend Stefanie Shimko-Lin, BSN RN CD-L CD-PIC FHIMSS once shared this cardiac analogy with me : "Collateral circulation is a workaround, that happens when the desired workflow doesn't work. If you make it easy to do the right thing, people will do it."

These analogies may all seem a bit peculiar and tongue-and-cheek, but if you're a clinical leader - I hope this blog post helps to spark helpful discussion and learning with your own clinical leadership and project teams, so that you can better solve the workflow and operational issues you might encounter in your daily clinical routines.

Remember, this blog is for educational and discussion purposes only - Your mileage may vary! Have any other helpful analogies or advice for new clinical leaders? Feel free to share them in the comments section below!

How to write gourmet policy and procedure

Hi fellow informatics junkies, workflow managers, and other clinical Jedi,

I love watching the Food Network channel. Not only because it lets you watch world-class chefs prepare unbelievable dishes, but because of the business and operational lessons they sometimes impart. Two of my personal favorites are Gordon Ramsay and Buddy Velastro, who not only bring a real love for food, but also demonstrate really smart business and operational sensibilities. I have always believed that healthcare could learn some lessons from the food industry.

With that in mind, today I'd like to address the subject of policy writing. To me, policy is like food -  If you don't like it, and it doesn't nourish you, why bother with it? It's not just enough to taste good - Good policy should also be good for you. 

Also, like food - Good policy creates harmony and brings people together. Holiday dinners are no fun to make if you are the only person making them. They become much more meaningful when you share the labor with your family, and have a chance to talk and communicate while you wash the vegetables and boil the pasta. The same applies to policy writing : It's not just the end result that matters - It's also the road you travel to get there. 

Writing great policy and procedure doesn't have to be painful - It's actually fun once you know the recipe. It can help you create clarity, harmony, and efficiency. So with that in mind, I'd like to offer up a great recipe: How to write a gourmet policy and procedure.

Now remember, because they can become the subject of legal inquiries when they fail, policy is something you should take your time to develop. For this reason, you'll also want to consult your legal advisor before undertaking any changes to your policy process.

Also remember, procedures are workflows - So by writing good policy and procedure, you are mapping out your core operational workflows! If you have an EMR and an Informatics team, you can save lots of time by making sure your procedures are well-written, since they are key tools used to configure your electronic medical record!

Now, before we get to the recipe, just so we're all on the same page - what's a policy, and what's a procedure?

• POLICY = Your standard
• PROCEDURE = How you will achieve that standard

These two are often found together on the same document, because once you define something as being a standard (policy) in your organization, you will quickly need to know how you are going to meet that standard (procedure).

This is where a common question comes up - Q:"Do you NEED to have the procedure on the same document as your policy?" A : No. Some organizations choose to just define policy - And then link the policy statement to a separate procedure document, e.g. "PROCEDURE : Please see the Lippincott Manual, page ____". Either way, if you are defining a policy standard in your organization, that you can legally be responsible for upholding - you should put a lot of thought into how exactly you will uphold that standard. 

Now - Let's get to the recipe!

A. PREPARATION :
The first step to creating a policy is asking the question, "Do I really need a policy?" You generally don't need to create policies for things that are common sense, don't benefit your organization, or impossible to enforce. On the other hand, you *do* want policies for the important operations of your organization, especially ones that are supported by regulations.

Once you've decided that you need a policy, the next step is doing some literature search, starting with your existing policy manual - Does any existing policy already address some or all of the desired standard? You will need to do this to ensure you don't have overlapping or conflicting policies. You will also want to review other current literature, to see if there are any regulations, studies, or best-practices which support the creation of your policy.

If there is no conflicting policy, then next it's helpful to gather the organizational policy template, policy style guide, and any regulations or articles you've found which support the creation of the policy. 

B. DRAFTING THE POLICY :
Once you have clarity on your need for a policy, including the regulations and any other citations which support the creation of the policy, you will want to then take your standard policy template and policy style guide, and start to write the policy statement.

Policy statements, ideally, are short and sweet, and should clearly state what your desired standard is. An easy way to think of writing them is using this template : 

"All __________ will _________ according to the procedures outlined below."

So, as a teaching example, let's make a "Cupcake policy" that makes it mandatory for all patients to get a cupcake on arrival to an inpatient bed : 

Now that you have drafted the policy statement, you will want the reader to figure out how they can achieve this standard by writing a good procedure.

C. DRAFTING THE PROCEDURE (with time/cost/labor estimates!)
To help support our new cupcake policy, we will want to figure out exactly how the organization will support this policy. This is the place where organizations can save a lot of time and money by writing a great procedure that helps create harmony during the policy review process. Remember - procedures are workflows, and working them out regularly will help create workflow clarity, making your policies tools of budgeting, education, and harmony.

The easiest way to write a clear procedure is to use the following template : 

[ WHO ] will/may [ WHAT ] [ where ] [ how ] [ when ] [ why ] [ time ] [ labor ] [ materials ] 

Where : 

• [ WHO ] = Role of the person who will perform this step of the procedure
• [ WHAT ] = Task they will do at this step of the procedure
• [ where ] = (OPTIONAL) Where they will perform this task (e.g. "in a bowl")
• [ how ] = (OPTIONAL) How they will perform this task (e.g. "with a spoon")
• [ when ] = (OPTIONAL) When they will perform this task (e.g. "until smooth")
• [ why ] = (OPTIONAL) Why they perform this task (e.g. "to prepare for baking")

So for our cupcake example, we might start by DRAFTING the following procedure : 

You will notice that by writing it using this template, you have started to answer some questions : 

• Who are the end-user stakeholders? (A: Kitchen staff, couriers, and inpatient nurses.)
• Who will need to help review this policy? (A: Director of Kitchen Staff, Director of Couriers, and Director of Inpatient Nursing)
• What is the cost of this procedure? (A: Time, labor, and materials of each step!)

In fact, if you wanted to get really fancy, you could potentially bring this procedure into a spreadsheet, and calculate the cost of the procedure to a penny!

I highly recommend playing around with your procedure in a spreadsheet like this - You will quickly figure out two things :

• How much, exactly, the policy will cost you (in this case, $326.40/day in materials and labor x 365 days a year = $119,136/year!)
• Where you might be able to save costs in this workflow (e.g. asking a courier to pass out the cupcakes, instead of inpatient nurses, could save you $80-$20=$60/hr savings x 3.33 hours = $200 savings a day x 365 = $73,000 savings/year!) 

Figuring out this cost will help prevent you from approving a policy that you don't have the resources to follow. And once you have this procedure (workflow) worked out to your satisfaction, you can then add the regulations/citations which support the creation of the policy : 

... and bring this DRAFTED policy to the stakeholders for review.

D. DETERMINING THE STAKEHOLDERS
Because this procedure was written with the above template, it's pretty easy to figure out who needs to review this policy before it's brought for final approval - The people responsible for the people who will do the task, usually something like : 

• The Director of Kitchen Staff
• The Director of Couriers
• The Director of Inpatient Nursing

So you will want to add their names to the "Reviewed By:" section of the policy (see below):

... and set up some time with these people to review the new policy. 

E. MEETING WITH STAKEHOLDERS TO REVIEW POLICY
Once you meet with these stakeholders, you will want to review the policy together and ask them three questions : 

1. Can your staff do the task(s) in this procedure?
2. Do you have the budget to pay for the staff to do the task(s) in this procedure?
3. Can you educate the staff to perform the task(s) in this procedure properly?

If the answer to any one of these questions is "NO", then it means that either the policy should be edited, rewritten, or delayed until issues can be resolved.

If the answer to all three of these questions is "YES", then ideally, you would seek their signature under the "REVIEWED BY:" section of the policy : 

In some organizations, you might need to seek additional signatures under the "Reviewed By:" section, such as a person from quality to review the policy name and coding are correct and that the spelling and citations are all correct. To see if there are additional signatures, you will want to refer to your organization's standard policy process, usually kept by your policy coordinator.

F. BRINGING FOR FINAL APPROVAL
Once you have the signatures required for final approval, you will again want to refer to your organization's standard policy process, and arrange for the policy to be approved and published. 

Ideally, there is only one signature required for approval, so that the policy can be briefly reviewed in a committee, approved by vote, and then whoever is authorized to approve policy for the organization then signs it, making the policy an active policy : 

Sometimes, usually for political reasons, some organizations have decided to require two signatures for approval, to create a system of checks-and-balances. While this is sometimes helpful, it can also delay policy approval if you don't have both people in the room at the same time. (E.g. one person might agree to sign the policy after a committee vote, but then the second person later decides not to sign the policy = This ends up delaying the approval and frustrating the committee.)

G. PUBLISHING YOUR POLICY
After approval, the person with authority to give final approval should then follow your organization's standard policy process to make sure that the policy is correctly indexed and published in the organization's standard policy manual.

Sometimes, policies will contain an "ACTIVE DATE:" in the language, to allow for policies to be approved before they become active (e.g. approving a policy in February for a project that goes live in March). If the policy clearly states the "ACTIVE DATE :", then you can place it in (or upload it to) your policy manual before the actual active date. 

When a policy is published to your organization's manual, you will now want to send a notice to the people who will be expected to follow the policy - In this case, the kitchen staff, the couriers, and the inpatient nurses.

Finally, you will want to make sure the stakeholders actually educate their teams about the new policy, and assemble whatever resources are necessary to start the new workflow on the expected start date.

H. MONITORING YOUR POLICY
Policies should be monitored for effectiveness by the stakeholders, as soon as they are approved and published. Sometimes the question arises, "What if someone breaks a policy?". While this is a problem, it should not mean immediate punishment or remediation. Instead, it should trigger an inquiry and discussion of what-went-wrong : Was the policy incorrect? Not educated properly? Not budgeted properly? Incorrectly written?

If the inquiry reveals no problem with the policy, then usually it is just a matter of some re-education or remediation, to correct the issue. This deficiency should still be tracked and noted for future review of the policy.

I. REVISITING YOUR POLICY
Policies should be reviewed at least every 2-3 years, to ensure that they are still effective, properly educated, and properly budgeted for. Sometimes organizations make budget changes that impact policy function - Ideally, you will want to catch those workflow changes as soon as possible, but by making it a habit to revisit your policy at a minimum of every 2-3 years, it will help make sure that your policy is accurate, functioning, and up-to-date with current regulations.


Remember - Good policy reduces cost and creates operational clarity and harmony. Bad policy does the opposite. Always review your policy needs, make sure you don't already have an existing policy/conflict, and review your organization's standard policy process and template before you start writing!

Finally, a great reference (for those seeking more information on policy writing) is Writing Effective Policies and Procedures : A Step-by-Step Resource for Clear Communication by Nancy J. Campbell (1997). It's a big book, but the first few chapters are fantastic in explaining the basics, and the rest of the book is a great reference for how to tackle more complicated policy issues.

I hope this has been a basic, helpful review of policy and procedure development! Always ask your policy coordinator and legal counsel for advice before making any changes to your current template or process! Feel free to leave your thoughts and feedback in the comments 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.