Monday, August 1, 2011

Informatics Curriculum for Medical Schools

There are currently lots of hospitals and doctor's offices looking to "go electronic" by getting an electronic medical record.

Some of those offices/hospitals, however, won't be able to make the conversion without a lot of pain.

Why can some places do this easier than others?

Part of the reason, the one that's commonly given, has to do with willingness to change - Will you be willing to support your EMR implementation? Will you pay for the software AND the support? Will you be willing to send your doctors and nurses for training? Will your doctors and nurses embrace the change?

And then there is another more difficult topic - Is your clinical paperwork well-designed?

Organizations that have well-designed paperwork will generally have an easier time of "going electronic". Organizations that don't, won't.

So what is "well-designed paperwork?"

This brings me to a topic that sometimes pops up in clinical informatics discussions - The need for some education on clinical informatics in medical school. 

Medical schools already have so much to teach - So whatever informatics education I can convey has to be short and sweet. So I started to dream of what I would teach, if I were invited to lecture at a large medical school, to help the students with their medical careers and running their practices/hospitals in a way that facilitates an easy transition to an EMR...

Doctors who generally understand these tools and design their paperwork by these divisions will have an easier time "going electronic". Doctors who mix these tools on the same paperwork will have a harder time "going electronic".

(So without further ado... Start the spacey, dream-sequence fuzzy-image noise...!)


Instructor : Professor D. Stanley 
Date : Now
Location : The comfort of your computer

Hi folks - Nice to meet you. I'm here to prepare you for thinking in a way that will help you in your future clinical practice.

No matter what you do clinically, you're going to be expected to work in a team. Good teamwork requires good communication. So it's really important, for you, your patient, and your other teammembers, that you know how to communicate properly.

In addition to being friendly, and well-spoken, and being a good listener - It's very useful for you to understand the informational tools you're going to be using to take care of patients.

So I'd like to tell you a little bit about those tools, so that you design and use them well.

An order is an instruction for a defined person to deliver a defined type of care to a defined patient in a defined way for a defined amount or duration. You'll notice I used the word "defined" five times in that sentence. It's because orders, to be safe, should be as well-defined as possible. Orders are the smallest unit of initiating patient care. (If you're going to be a doctor, you're going to be creating a lot of them, so you should learn to make them safely.)

One of the first mistakes people make is mistaking other things for orders. As a general rule, orders should not be more than a line long - If they are, it's usually a red flag that what you're writing may not actually be an order.

In the paper world, putting other things down as orders isn't so bad because human brains will still be able to sort through the different types of tools, and nurses will know what to do with them. In the electronic world, however, poor order organization will lead to difficult EMR installations and HealthIT implementation problems.

Generally, orders are categorized by the people who are expected to follow them. So for example, you might find :
A. Pharmacy/Medication Orders - Used by nurses and Pharmacists
B. Nursing Orders - Used by Nurses
C. Diet Orders - Used by Nurses and Dietary Staff
D. Respiratory Orders - Used by Nurses and Respiratory Therapists
E. Activity Orders - Used by Nurses and Physical Therapists
F. Laboratory Orders - Used by Nurses, Phlebotomists, and Laboratory Staff
G. Imaging Orders - Used by Nurses and Radiology Tech staff

Another common mistake : Writing protocols as orders. Protocols are any "if-then" statements you might think of writing - If it's got a condition, where you expect a nurse to interpret a condition before taking another action, it's a protocol.  For example, "Give aspirin 325mg PO x1 dose STAT unless patient is bleeding" is actually a protocol. Even the text "These orders are only to be used while the patient is in radiology" is actually a protocol.

And another common mistake : Writing patient instructions as orders, e.g. "Change catheter dressing every 7 days after discharge" might sound like a nursing order, but it's really an order to the patient.

Some examples of good and bad orders, with comments :
- Aspirin 325mg PO x1 dose STAT - good order
- Morphine 2mg IV q30min PRN moderate pain - Because it has no duration, this could be a dangerous order if it's not automatically re-evaluated in 2-3 hours
- Morphine 2mg IV q30min PRN moderate pain x 3 hours - By assigning a duration, this becomes a safer order
- Morphine 2mg IV q30min PRN moderate pain x 3 hours Comment : Hold for sedation - By adding a comment reminding the nurse to hold the drug if the patient becomes sedated, this becomes a safer order
- Aspirin 325mg PO x1 dose STAT Comment : Hold if patient is bleeding - Because there is a conditional (IF/THEN) statement, this is actually a protocol.
- Change catheter dressing every 7 days : Unless the patient is actually in the hospital for 7 days or more, this is more likely a patient care instruction than a nursing order.
- Chest X-ray STAT : While this might be acceptable, it does not contain an indication and there may be billing problems. It also does not tell a radiologist what you are looking for, so they could miss what you're looking for.
- Chest X-ray STAT Indication : Cough, sputum, acute shortness of breath, rule out aspiration - By adding an indication, this will avoid billing problems. By adding detail, the radiologist can cue in on the clinical question you're asking. 
- Advance diet as tolerated - This does not help a nurse understand what diet they should be aiming for, nor how to advance the diet, nor in what timeframe they should try to advance it. Because this actually has a great deal of IF/THEN logic, in short, this is really a protocol.
- Advance diet to regular diet as tolerated - This helps a nurse understand that you're aiming for a regular diet - Better than the above diet order, but it is still a protocol.
- Advance diet to regular diet, no texture modification, no liquid modification as tolerated - This is even better because it tells a nurse what diet to advance to AND the texture and liquid modification that the patient might need - But from an informatics perspective it is still a protocol.
- If K+ < 2.5 then give KCl 40 mEq PO x1 dose - First, because it has an IF/THEN, this is actually a protocol. Next, writing "KCl 40 mEq PO x1 dose" could be misread as "KCl140 mEq PO x1 dose".
- If K+ < 2.5 then give Potassium Chloride 40 mEq PO x1 dose - Still a protocol, but at least there's no chance for the "l" in "KCl" to be mistaken for a 1.
- Percocet 5/325mg 1 tab PO QID PRN - Some folks might not realize that QID actually has set times - 8am, 12pm, 4pm, 8pm - So technically this could only be taken during daytime hours. (Is that the intent?) The PRN also does not specify the reason to take the Percocet, so a patient could take it for any pain. (Is that the intent?)
- Percocet 5/325mg 1 tab PO q6h PRN - This is a little better, because it would allow a patient to take it every six hours, even overnight. Still does not describe the circumstances in which the doctor would recommend to take the Percocet.
- Percocet 5/325mg 1 tab PO q6h PRN moderate pain (4-6) - This is even better, because the PRN is better described, so the nurse/patient knows when to consider giving the Percocet.

The best way to know whether or not an order is a good or bad order is to test the order in a test environment - Have a doctor write or enter the order on a "dummy" patient, and have a nurse read it. Then interview the nurse about how they would act and what they would do. It also helps to ask someone with experience/training in ordering safety.

The take-home point : Orders should always be well-defined for safety. Always test them if you have any questions.

Order sets are groupings of orders used to standardize and expedite the ordering process for a common clinical scenario. Unlike protocols, order sets contain orders that are started, modified, and stopped by a physician/LIP.

For safety and proper functioning, order sets should only contain orders. (See above.) Protocols, policies, procedures, guidelines, patient instructions, and staff instructions should generally not be built into order sets.

Optimally, for efficiency, order sets should be divided into one of three categories :
      - a. - Admission order sets - Those that standardize the ordering process for a common admitting scenario.
      - b. - Diagnosis order sets - Those that standardize the treatment for a common diagnosis/procedure
      - c. - Convenience order sets - (e.g. "Quick pick" lists) - Those that standardize the ordering process for a common clinical objective not described in a. or b. above. 

Clinical Pathways are groupings of order sets used to standardize the treatment of a common clinical diagnosis. They contain orders which are started, modified, and stopped by a physician/LIP, and are generally used daily throughout a patient's hospitalization.

Protocols contain orders which are started/modified/stopped by a nurse, pharmacist, or other healthcare professional based on a well-defined condition. They contain the IF/THEN logic that helps automate and standardize a clinical process, and if well-designed, can actually help increase safety and efficiency.

The challenge with protocols is designing them well. Because they contain orders which are started, modified, and stopped by a nurse, pharmacist, or other healthcare professional based on a well-defined condition ("discrete data element" in informatics terms), they require significant safety evaluations.

Common examples of protocols might be the "Heparin titration protocol", the "alcohol detoxification protocol", and even the "PPI Substitution protocol". These should all be published in a similar manner, executed in a similar way, and re-evaluated continuously.

Guidelines are general instructions about how to accomplish a particular task, but have much less medicolegal weight than a protocol or policy/procedure. Guidelines are generally more flexible, and can be useful for a clinician to understand a clinical process but still allow modifications depending on clinical circumstances.

A policy is a written standard of the organization. A procedure is a set of detailed steps which describe how to achieve the policy objective. For this reason, they are commonly published together on the same document, although technically, a procedure does not have to be a mandated standard.

As a rough outline, policies are usually divided into :
  - Clinical Policies (and procedures) - Those that describe standards related to patients and patient care
  - Administrative Policies (and procedures) - Those that describe standards related to employees and employee issues.

Because policies and procedures should be 'written with maximum clarity for them to be effective, they generally should only be written by people with experience or formal training in policy writing.

For easy access, policies and procedures should be published in a common, easy-to-access area.

Algorithms can be thought of as graphical representations of procedures.

Documentation/Forms are the tools used to record patient condition, vitals, responses, therapies, and outcomes in date/time order. If designed properly, these can also help standardize clinical processes and streamline care. Types of documentation can include :
   - Notes (e.g. H&P, discharge summary, nursing notes, respiratory therapy notes, etc.)
   - Checklists
   - Consents
   - Flowsheets (e.g. vitals, pain, drips, vents, etc.)
   - Labs
   - Radiology/Imaging
   - Other technology results

A Staff Education Module is a document that teaches a staff member about a particular educational objective. It could contain text, photos, videos, or other tools needed to communicate the educational objective to someone else. For effectiveness, it should contain a short quiz to document understanding of the educational objectives.

A Patient Education Module is a document that teaches a patient about a particular educational objective. It could contain text, photos, videos, or other tools needed to communicate the educational objective to a patient. For effectiveness, it should be very clear, and should contain a short quick to document understanding of the educational objectives.

A clinical staff schedule is a document that outlines the employee(s) responsible for patient care at a particular date/time. It should be published in a standardized manner in a standardized location.

A template is a document used to help build, standardize, and expedite the building of another document. Some common examples might include the "Order set template", the "Admission H&P Template", the "Discharge Summary Template", and the "Policy Template".

Because templates can be used to expedite and standardize the creation of another document, great care should be taken to avoid "auto-documentation"-type workflows which can run into billing/legal issues.

A glossary is a document with a list of commonly-used terms in alphabetical order, along with their definitions. By having an organizational glossary in a common area, it allows all members of the organization to standardize their definitions and language.


I hope this was useful to you all - Again, your mileage may vary greatly, so please check with your local laws and regulatory bodies before setting up your own paperwork and processes - but from a functional, pure-informatics standpoint, these would be the chapters in my "clinical informatics book".

Feel free to write with any comments or questions - Discussion on this blog is always welcome! :)