Some Factors Underlying Efficient Change Management

Recently I had a great discussion with a non-healthcare person about the role of Informatics in EMR implementation, and what kind of things CMIOs look for to estimate whether a particular EMR implementation will be successful or not.

The discussion was a great opportunity for me to really think about the big picture issues, and try to distill them into something more tangible to a non-healthcare, non-informatics audience. 

What it finally came down to, for me, was the successful planning and budgeting for the whole EMR implementation - both the go-live, and the eventual optimization and continued maintenance that come afterwards. It's not unlike buying a car - To be successful at car ownership, you have to budget for both the car (necessary at go-live) and the gas/maintenance (necessary after go-live to make the car go forward) :

While researching for this blog post, I found out this is one of the reasons why the mandatory price stickers on all new cars (known as the Monroney sticker) must contain both the price of the car and an estimate of the gas mileage :

Not only does this allow consumers to select cars with better fuel efficiency, it also helps a consumer answer the question "Can I afford this car?" before they actually buy it - A major factor for successful car ownership.

With most healthcare technology, it's pretty easy to budget for the car - vendors know this number well - but it's not as easy to budget for the gas. Vendors will often estimate the cost of optimization, upkeep, and maintenance for you, but how do you really know if their estimate is correct? Will you see the same gas mileage in your experience?

This then raises the question - What exactly are the factors that go into 'gas mileage' for an EMR? CMIOs, CNIOs, and other Informatics professionals struggle with these questions all the time, because they are important to help budget for successful EMR implementation :

• Budget well for the ongoing optimization, maintenance, and upkeep - And your EMR implementation will likely be successful.
• Budget poorly for the ongoing optimization, maintenance, and upkeep - And your EMR implementation may be fraught with struggle.

What experienced Informatics professionals know is that a large part of the 'fuel-efficiency' of EMR ownership comes from the organizational change management - How well-suited is the organization to make change? Does it contain the infrastructure and configuration needed to support efficient change management? 

These change management issues are so key to EMR implementation that in 2013, the website www.HealthIT.gov published this great primer on EHR change management :

https://www.healthit.gov/sites/default/files/tools/nlc_changemanagementprimer.pdf 

 ...which provides a great high-level overview about change culture, along with some fantastic references. (A helpful document and a must-read for any healthcare executive considering an EMR installation or replacement!)

But what are the other factors that experienced informatics professionals look for in change management? Are there other factors to look for that help better estimate your gas mileage, and thus your eventual cost of ownership? To help share some insights, I've created the following table, with some factors that I believe influence an organization's ability to manage change efficiently - In estimating the price of your gas, some factors to consider (in no particular order) include : 

While this list is by no means comprehensive, these are some of the bigger factors that experienced Informatics professionals consider before advising organizations how to best budget for their EMR implementations.

In the end, enterprise EMR success depends on correctly budgeting for the purchase, maintenance, and upkeep of your technology. It's not just your go-live that matters. Knowing the price of both the car and the gas before you invest will help you have a successful long-term implementation.

This post is for educational and discussion purposes only - Please consult your own Informatics professional before budgeting for any technology purchases. If you have any feedback, thoughts, or other factors to consider, please leave them in the comments section 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!

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 Sneakers. The committee celebrates the victory, and the secretary documents the vote in the committee minutes. People 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 Sneakers. The 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!

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!

What is your EMR documentation index costing you?

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

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

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

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

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

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

[ START OF RESPONSE ] 

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

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

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

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

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

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

Where :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hope this helps! Good luck!

- Dirk :)

[ END OF RESPONSE ] 

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

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

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