Sunday, April 3, 2011

What is a Procedure?

For my fellow informaticists, struggling to explain both "why it's more complicated than it seems" and "Still, it doesn't need to be complicated"...  I present : The Procedure.

The procedure is the workhorse of the Informatics Toolbelt. It's the hammer. Or the electric screwdriver.  (In food terms, I suppose it would be the meat-and-potatoes, or the rice-and-beans - depending on  your taste.) :)

The procedure is often the secret key to good informatics work products. It's often unloved, and misunderstood, but you'd be surprised how often I've been asked to "write a protocol" that actually turns out to be a procedure, or series of procedures.

When people talk about "mapping out the workflow", the procedure is often the starting point, the basic building block, and generally sets the framework for the rest of your workflow map.

When trying to map out a workflow, I generally recommend starting with the procedure. Most of the time, you will identify the other tools you need just by starting with the procedure(s).

A good way to teach yourself to think linearly, to write an effective procedure, is to read food recipes. These are essentially procedures. They help you understand the relationship between process and outcomes. (If Procedure = Process, then Policy = Outcome.)

By working out the procedure correctly, you can learn a lot about the safety before the procedure is ever implemented. In this way, well-written procedures can help reduce risk and create clarity.

I. BACKGROUND

A procedure is a detailed series of steps that should be taken to accomplish a defined goal. It's the clear list of instructions.
  1. It should not be confused with a protocol. Protocols contain the conditional (IF/THEN) statements that  allow a nurse, pharmacist, or other licensed health professional to start, modify, or stop an order on behalf of the protocol. Protocols are generally turned on/off with a physician order. 
  2. It should not be confused with a policy. Policies are stated goals/standards for the organization. While some procedures are paired with policies ("Policies and Procedures"), the policy is only necessary if you wish to "mandate" use of the procedure. If a procedure is not paired with a policy, it is optional. If a procedure is paired with a policy, then it should be a standard of the organization.
For this reason, procedures are sometimes published :
  1. With a policy - ("Policies and Procedures") - When use of the procedure is a "mandated organizational norm"
  2. Without a policy (e.g. Nursing Procedure Manuals, commonly found on most patient floors) - When use of the procedure is an option
II. DESIGN / CATEGORIZATION

Procedures should be written with clarity, simplicity, and with the end-user in mind. They should carefully balance specificity and ambiguity. Because procedures should communicate "how to achieve the goal", the steps should generally be numbered in order.

For best practice, it is helpful if each line of a procedure generally follows this format :
[ who ] will/may/should/must [ what ] [when] [where] [ why ] [ how
Where :
[ who ] is the person who will perform that step in the procedure, generally best described by job title
will/may/should/must - Choose this wisely. Some people advise never to use "will" or "must" because it creates a very clear standard which can cause challenges if you fail to meet that standard. Speak to your organization's legal counsel for advice about this. 
what ] is the exact activity the person will perform
[ when] is the time they will do it (OPTIONAL - e.g. "Until hands are wet" or "After patient is comfortable", only if needed to clarify the procedure )
[ where ] is the location they will do it (OPTIONAL - only if needed to clarify the procedure)
why ] is the reason they should do this (OPTIONAL - only if needed to clarify the procedure)
how ] is a short description of the way they will do it (OPTIONAL - only if needed to clarify the procedure)
For example, one might write a procedure for washing hands :
  1. Employee will approach sink
  2. Employee will turn on water at sink until water is warm to touch
  3. Employee will rub hands under warm water for 10 seconds
  4. Employee will dispense 10mL of liquid soap into hands
  5. Employee will rub hands together vigorously for 30 seconds
  6. Employee will run hands under warm water for 20 seconds
  7. Employee will turn off sink with elbows
  8. Employee will dry hands with paper towel from paper towel dispenser
  9. Employee will throw paper towel in garbage
This, of course, can be reformatted for simplicity as :

A. Employee will :
  1. approach sink
  2. turn on warm water
  3. rub hands under warm water for 10 seconds
  4. dispense 10 mL of liquid soap into hands
  5. rub hands together vigorously for 30 seconds
  6. run hands under warm water for 20 seconds
  7. turn off sink with elbows
  8. dry hands with paper towel from paper towel dispenser
  9. throw paper towel in garbage
You will notice in the above examples that there are no "IF/THEN" statements. These are best kept to protocols, especially if the procedure involves a nurse/pharmacist/other licensed medical professional starting, modifying, or stopping an order on behalf of the physician.

Remember, that when writing a procedure, one should keep in mind : What will you use the procedure for?
  1. Procedures can easily be converted into "instructions" for patients to use (e.g. if you want a patient to learn how to donate blood)
  2. Procedures can easily be paired with "Policies" to mandate a particular way of doing things (in this way they help standardize care)
  3. Procedures can be left alone, and published in a lone "Procedure Manual", to help your staff understand the best way to accomplish a particular goal.
It should also be asked : Do I need to write this procedure? As you can imagine, once you understand how to write a procedure, it can become tempting to write procedures for everything your organization does. I recommend you only write procedures when there is a :
  1. Clear need to standardize a process (so you probably want to pair it with a policy)
  2. Clear need to educate a process, but don't need it to be mandatory (in which case you probably want to publish it in a lone procedure manual or as a "set of instructions")
Finally, remember that many procedures can be quite complex. If there are multiple team members involved in accomplishing a particular goal, the "who" in each line should be clearly stated, preferrably by job title. For example :
  1. Attending Physician will place order "Consult Gastroenterology" in patient's chart.
  2. Attending Physician will contact GI Consultant to arrange for evaluation and consultation.
  3. GI Consultant will evaluate patient
  4. GI Consultant will order "Milk of Magnesia 30mL PO x1 dose STAT" in patient's chart.
  5. Floor Nurse will give Milk of Magnesia as ordered
III. OWNERSHIP

Procedures will, like most clinical tools, require monitoring and upkeep. In general, they should be re-reviewed every 2-3 years, or more frequently if needed. For this reason, I recommend that procedures are owned by a clinical or administrative director who has been assigned to monitor and update the procedure as needed.

IV. CONSTRUCTION

It is recommended that procedures be written by someone experienced or trained at writing procedures (e.g. an experienced policy writer, informaticist or other specially-trained person), in conjunction with one or more subject matter expert(s).

Because the goal of a procedure is to communicate "how", they should use simple language that an end-user can easily understand.

First, a draft procedure should be constructed by the informaticist and the subject matter expert(s).

V. TESTING

The draft procedure should then be tested, in a testing environment, using at least one fictitious but realistic scenario and at least one representative from each job title found in the procedure.

After testing has been completed, the builder/policy writer/informaticist should examine the needs for the procedure, and decide whether :
  1. The procedure should be paired with a policy and published in a policy and procedure manual
  2. The procedure should be published in a lone procedure manual.
VI. APPROVAL

After testing has been completed, and decisions have been made (as to whether it needs a policy), the procedure should be brought to a committee for approval.

The committee should examine the goals of the procedure, testing results for the procedure, and the publication plan for the procedure :
  1. Will it be paired with a policy?
  2. Will it be published as a lone procedure?
  3. Does it need to be converted to more patient-friendly "instructions"?
If the approval committee feels the procedure is evidence-based, well-tested, and safe, it should be brought to a vote.

If the approval committee votes to approve, then the procedure may be published for clinical use.

Please note : Some procedures (including many nursing procedure manuals, e.g. Lippincott) have subject matter experts and editors who thoroughly examine/test/vet/approve the procedures for use before publication. These procedures may generally be assumed to have been approved for use by the Lippincott editors, but your organizational standards may vary.

VII. PUBLICATION

After approval by committee, procedures should be published immediately :
  1. In a Policy and Procedure Manual - For those procedures paired with policies
  2. In a Procedure Manual - (e.g. Nursing Procedure Manuals kept in many clinical areas) - For those lone procedures which do not require policy mandates
Both of these manuals should be kept in the open, in a common place, where all end-users can easily find and review them.

VIII. EDUCATION

After publication, it is helpful if clinical staff is made aware of the publication of the procedure. Emails, posters, staff meetings, and sometimes classroom instruction can be helpful in educating staff about a procedure.

If the procedure is kept in a common, easily-accessible place, the procedure will require less education effort to be effective.

IX. MONITORING

After implementation/education of a procedure, it should be monitored for effectiveness and safety by the owner.

X. CITATIONS


http://www1.ucsc.edu/ppmanual/pdf/guide.pdf - UC Santa Cruz document about policy and procedure writing, and why policies, procedures, and guidelines should all be kept separate

http://en.wikipedia.org/wiki/Policies_and_procedures - Wikipedia article on Policy and Procedure - Please note the distinction between "Procedures" and "Policies and Procedures". (I also recommend some additions to their "standard template".)

http://www.bizmanualz.com/information/2007/11/12/why-do-you-need-to-write-procedures.html - Good piece about managing risk using well-written procedures

**My absolute favoriteWriting Effective Policies and Procedures : A Step-by-step Resource for Clear Communication by Nancy J. Campbell, AMACOM publishing, 1998. (If you buy one book this year, to help you do this - I recommend this one.)

Hope this was helpful! Would love comments, or your own stories about writing procedures!

No comments: