Rethinking #Healthcare management with #SimHospital

So I'm at the HIMSS12 conference in Las Vegas this week, where it's been very inspiring - Meeting lots of #HealthIT and #Informatics people with whom I share a lot of the same passions and thoughts. Breakfast started with Eric Dishman (@ericdishman) of Intel talking about "Big Data", the greying of the world population driving the need for technology solutions to healthcare and importance of disruptive innovation. Biz Stone (@biz) of Twitter opened up the keynote today, talking about opening up information flows and the modern information revolution. The common theme at this conference seems to be : A need for disruptive innovation to help drive development of a more efficient, more personalized, and more distributed healthcare model.

For example, yesterday at the #CMIO forum, after listening to all of us share stories, it became clear that two of the important roles of a #CMIO are to be a thought leader and to be a cautious steward of disruptive innovation that really helps patients. 

Of course, since I'm passionate about creating #Informatics platforms and well-designed tools that clinicians and administrators can use to work together, I thought : Could I look a step higher, and develop something that helps more than just the clinicians? Could we make something that helps healthcare efficiency on a national level?

And so for inspiration, I turned to a common theme in engineering and development : The three worlds of development.

A. THE THREE WORLDS

Engineers and software engineers are very familiar with this concept - Clinicians, administrators, and politicians generally aren't. 

One of the fundamental tenets of good Informatics is understanding the way ideas come to fruition in a safe and organized way - By moving an idea through three different stages of organized development :

1. The DEVELOPMENT stage
2. The TESTING stage
3. The LIVE (sometimes called "PRODUCTION") stage

Huh? What does this mean, exactly? 

To help develop things in a safe, controlled, and predictable way, most engineers think long and hard about:

1. How can I DEVELOP an idea safely?
2. How can I TEST an idea safely?
3. How can I make something go LIVE safely?

And so, most engineers and informaticists are familiar with these three different worlds and how to use them : 

1. "DEV" - (the "development" world) - Typically, used by people who help build/develop the idea
2. "TEST" - (the "testing" world) - Typically used by those end-users who test the idea
3. "PROD" - (the "live" world) - Typically used in real-life by those people who actually use the idea

So if you train your brain to think about these different stages of organized, controlled development, you will actually be better at developing things in an organized and predictable way.

The funny thing is that often these three worlds are used by engineers and Informaticists, but the rules actually apply to many, many other things we develop in real life, whether we realize it or not. For example, many people live in a house :

1. "DEVELOPMENT PHASE" of House : Point where builder is building the house according to specifications
2. "TESTING PHASE" of House : Point where safety inspector looks at house design and tests for adequate safety
3. "PRODUCTION/LIVE PHASE" of House : Point where person moves into house

Or you might send an email :

1. "DEVELOPMENT PHASE" - Point where you are writing and drafting the email
2. "TESTING PHASE" - Point where you are proof-reading the email and checking the spelling
3. "PRODUCTION/LIVE PHASE" - Point where you click "SEND" and make the email a reality

Or you might send a paper letter to someone :

1. "DEVELOPMENT PHASE" - Point where you are writing and drafting the mail
2. "TESTING PHASE" - Point where you proof-read the letter before putting it in the envelope
3. "PRODUCTION/LIVE PHASE" - Point where you drop the letter in the mail to make it a reality

So I usually recommend to new Informaticists that they should become familiar with these three worlds, and :

1. Who uses which world for what?
2. What process will you use to transfer ideas from one world to the other?

It's also why I personally feel that some older healthcare change concepts like 'Test of Change' are kind of outdated - They only encourage crossing over from one world to the other without a formal process. 

Again, a good Informaticist understands these three worlds, how to use them, and helps an organization define the standards by which tools will be moved through these three stages of development. Generally, with regards to Health IT development :

1. Software engineers/analysts live in the "DEV" world (often with help of an Informaticist)
2. Owners/End Users live in the "TEST" world (often with the help of an Informaticist), and 
3. Real-life people live in the "LIVE" world.

B. THE CONCEPT : SimHospital

So to help HIMSS and the ONC drive some really innovative thinking about bending the healthcare cost curve, I wondered - Could we actually use these common engineering/informatics principles to help more than just software engineers and informaticists? In other words, could we use these principles to help patients, administrators, clinicians, and politicians understand healthcare better? How would we do that? 

So it dawned upon me, a great tool that could help improve healthcare management and delivery would be a robust TESTING GROUND for healthcare change. Enter the idea : SimHospital.

SimHospital would be a computer-modeled, virtual hospital where all of the basic characters in healthcare could live in a safe, virtual environment that allows for testing. Just like the popular  SecondLife world or TheSims series, it would be a virtual hospital with virtual-reality avatars that are built to behave much like their real-life counterparts - E.g. virtual patients, doctors, nurses, pharmacists, respiratory therapists, couriers, and other hospital staff could all be designed to behave in fairly predictable manner, based on certain variables like :

1. Education/training
2. Allowed tasks
3. Predicted compliance with tasks
4. Clinical tools and communication to facilitate interactions between team members
5. Contracts and Policies to guide behaviors

And I think in this virtual, simulated world, we could allow better testing of ideas like :

1. How will changing a policy or regulation impact care?
2. How will changing a clinical or administrative tool impact care?
3. How will changing a workflow impact resources?
4. How will adding/removing a department impact workflows?

This virtual world would also be an amazing training tool for clinicians, administrators, and politicians - If we commonly ask pilots to train hours in a flight simulator, maybe this SimHospital could be used to train healthcare leaders to understand their environments better.

It could also, if developed, be used as a tool to help do predictive modeling for healthcare outcomes - If the ACO movement is going to make organizations responsible for both the delivery and outcomes of healthcare, then SimHospital could be a very useful tool to predict the outcomes of a particular intervention.

And if we wanted to expand beyond the boundaries of the hospital, we could also develop SimHealthcare to model the hospital and outside PCPs and specialists, again, to help predict how a change in one or more variables will probably lead to what results.

I think it could be a pleasantly disruptive way of improving education for healthcare leaders and simultaneously help with the predictive modeling that will be required for ACOs to succeed. 

As with many of my posts, I'd like to throw the idea out there, and would be interested in hearing comments. (Do I have any readership from SecondLife or TheSims programmers who want to use their skills to help reform healthcare?) :)

Remember : This blog is for education/discussion and brainstorming only. Your mileage may vary. Always interested in hearing your thoughts and comments!

Could a new note, the Football, help improve healthcare?

As I've mentioned in previous posts, the American government cannot set up a national patient identifier. So projects like NHIN Direct generally rely on a document push mechanism which, essentially, allows one healthcare provider to push an authorized, HIPAA-secure document to another healthcare provider.

I'll admit it - I wish we could have pull.

The reason I want pull? A centralized, patient-centric medical record (like in the #SpeakFlower model) would make it much easier for various providers to pull and update information in a virtually central location. Pushing documents is going to have its workflow challenges, and leave some with the question, "Where is the patient's real chart?".

So since I recently became involved in our Massachusetts discussion on Health Information Exchange, I'm struggling with the question of how to implement a state-wide HIE system that will allow providers, at least initially, to push documents to eachother.

So my first informatics question, on being given this challenge, is : What will people push? Who will push it? And to whom? And when?

To try to answer these questions, I invited folks to our last Interstate 91 Informatics dinner in January to discuss "Can we do better than SOAP?" by asking everyone :

1. What documentation do people want?
2. Could we develop any group standard templates for standardized documentation, to save us all development costs?
3. Could we develop any rudimentary, area-wide clinical governance so we can share documentation easier, and thus all benefit from a common language?
4. Ultimately, who will push what documentation to whom, and when?

And after a rousing discussion, the answer I heard was this : Everyone has a different opinion.

I guess it's entirely understandable... ICU docs, PCPs, surgeons, specialists, hospitalists, and everyone else has a common goal - making the patient healthier - but they have different training and thus they all have different needs. This is why when I hear docs say "I just need the important information!", I smile because ultimately, all of the information in a chart is important - It just depends on your context and clinical needs.

So I'm left with the ultimate Informatics challenge - How can we get the right information to the right person in the right place in the right time in the right way? Especially when everyone has a different opinion on what the right information is?

And is there any way we can develop a standard lingua franca that all doctors speak?

Is there something that all docs would know how/when to use, in a standard way?

THE CHALLENGE

So to better understand the challenge here, I looked to the most common issues I hear doctors, nurses, and administrators talking about :

1. Med Reconciliation (at virtually every stage of care)
2. Handoffs inside a hospital
3. PCPs wanting notification that their patient has been admitted
4. PCPs wanting discharge summaries when their patients are discharged
5. Quality
6. Waiting times

And given the push mechanism it looks like we are going to get, at least initially, how are we going to set any standards?

There is one thing issues #1-6 above share : They are mostly all caused by the lack of a common, portable, #SpeakFlower-type, patient-centered chart, which we currently lack in modern private healthcare. (Note : I say private healthcare because the Veteran's Administration/VA VistA system actually has a pretty seamless, continuous, portable patient chart that only works inside the VA system for various political and cultural reasons...) 

But in a private, push world, is there any way we could we start to approach some kind of a portable, patient-centered chart?

In other words, is there any way we could leverage our push system in a way that actually simulates a patient-centered chart?

And how would we implement this?

THE CURRENT STATE

Looking at the current buffet table of documentation, it's no wonder that every doctor has a differrent opinion of what they need. There aren't really any hard standards for clinical documentation. As I've mentioned in previous posts, most doctors learn about documentation from things like the Washington Manual Internship Survival Guide. So as a result, most physicians are familiar with things like :

1. Admission H&P
2. Progress Note
3. Discharge Summary
4. Transfer Note
5. Encounter Note
6. Procedure Note
7. Visit Note
8. Consult Note

And so when our Interstate 91 Informatics group got together, it's no wonder every doctor had a different opinion of which note they would want to get, and when.

So to look for inspiration on how to build a standardized document that every doctor would know how to use, and when to push to whom, again I thought : Could we make a standardized push document that approaches the portable, patient-centered chart we all want?

THE INSPIRATION

It dawned upon me that to solve this problem, we will need a new type of note. And so if it's something that's not in the Washington Manual Internship Survival Guide, it would have to be something that was so useful, so intuitive, and so desirable - like McDonalds French Fries - that every doctor would *want* to use this note, update it, and push it to the right person at the right time.

So then I thought - We are really asking for a portable, mini-chart that we can push around to the next provider.

And then I wondered, "What will we name it?" The "Mini-chart"? The "Patient Summary"?

What we're really talking about here is a "Patient Handoff Note" - The 'mini-chart' - And to make it extra-intuitive, I've decided to nickname it "The Football".

(Interestingly - "The Football" is also the nickname given to the "Nuclear Football" which the President of the United States carries around at all times, which according to Wikipedia is designed to be "a mobile hub in the strategic defense system of the United States" - A portable, role-centric tool for making important decisions... Huh! Talk about portable documentation!)

Also by nicknaming it "The Football", it gives users a visual clue about how to use it and when to punt it to the next physician.

THE PATIENT HANDOFF NOTE ("FOOTBALL")

The Patient Handoff Note ("Football") is basically a patient mini-chart, designed to be used in handing off care from one physician to another. In other words, physicians could think of the Patient Handoff Note ("Football") as a document that they update and push to the next physician expected to see the patient.

Who is the next physician expected to see the patient? Whoever is expected to see or cover the patient next. If you're a PCP expecting a specialist to see your patient, you'll update the football and send it to the specialist. If you're a specialist done with the consult, expecting the PCP to see the patient next, you'll update the football and send it back with the patient to the PCP. 

Of course, the key word here is expected - What if a patient has an unexpected trip to the ED?

I thought the note should be of such high value that, on arrival, the ED physicians would request the Football from the PCP. (By doing this, they would ensure the PCP knew about the visit.) And when the ED doc decides to admit the patient to the Hospitalist, they would update the football and push the patient and football to the expected Hospitalist.

And the admitting hospitalist could update and push the football to the expected hospitalist the next day. 

And the daytime hospitalist could update the football and push it to the expected overnight covering staff. 

And the overnight covering staff, if needed, could update the football and push it to the daytime hospitalist.

And the daytime hospitalist, on discharging the patient, could update the football and push the patient and football back to the PCP.

(To the patients reading this, I apologize - This is really referring to document management, not patients - I am definitely not endorsing pushing patients around!) :)

So anyway, back to the football - what could this Patient Handoff Note ("Football") look like?

Here's my first draft - As an example, I'll show how it could be used at the point of discharge :

[ DRAFT ] PATIENT HANDOFF NOTE ("FOOTBALL")

PATIENT NAME   :   VADER, DARTH A.

DATE OF BIRTH   :   Jun 06 1966

Emergency Contact :

Tarkin, Emperor

Relationship : Father

Cell (914) 555-1212

CODE STATUS : 

Full Code (last verified by Luke Skywalker, MD, PCP, Internal Medicine, Oct 30 2009)

DATE OF HANDOFF :

Feb 03 2012

HANDOFF FROM :

Dirk Stanley, MD (Hospitalist, Internal Medicine)

EXPECTED HANDOFF TO :

(   ) Overnight Coverage 

(X) Other : Luke Skywalker, MD (PCP, Internal Medicine)

AUTHOR : (Note : This is who is pushing the football today)

1. Feb 03 2012 - Dirk Stanley, MD (Hospitalist, Internal Medicine)

CO-AUTHORS : (Note : this is essentially everyone who has pushed the football in the past, with last date they pushed it, in reverse date order)

2. Jan 28 2012 - Han Solo, MD              (Attending, Emergency Medicine)

3. Sep 22 2005 - Beru Whitesun, MD    (Attending, Gastroenterology)

4. Apr 02 2004 - Luke Skywalker, MD (PCP, Internal Medicine)

5. Apr 01 2002 - Ben Kenobi, MD        (PGY-1, Internal Medicine)

6. Feb 22 2002 - Owen Lars, MD         (Attending, General Surgery)

7. Jan 11 1996 - Leia Organa, MD        (Attending, Cardiology)

ALLERGIES :

1. Mar 29 2002 - Bactrim (Rash/Hives)

PMHx/PSurgHx : (Note : This has all problems/history identified in reverse date order)

1. Feb 03 2012 - Aspiration Pneumonia

2. Feb 25 2002 - Cholecystitis, s/p cholecystectomy

3. Sep 22 2005 - Colonoscopy, s/p benign polyp removal

4. Jan 11 1996 - CAD s/p NSTEMI, no catheterization, medical management

5. Oct 12 1994 - Hyperlipidemia

6. Apr 03 1992 - HTN

SIGNIFICANT STUDIES : (Note : This is noted by docs, again in reverse date order)

1. Jan 28 2012 - 2-view Chest X-ray = (R)LL patchy infiltrate

2. Jan 04 2004 - PSA=0.06

WHAT I DID :

Patient admitted to Mos Eisley Hospital on 1/28 with cough, fever, purulent sputum approx 3d after being found asleep and intoxicated at a party. Chest X-ray showed (R)LL infiltrate, WBC=21k, PMNs=80%. Started Zosyn IV and after 3d patient improved. Changed to oral Augmentin on 2/2/2012. Now ready for discharge today 2/3/2012.

ACTIVE MEDS (AT TIME OF HANDOFF) :

1. Lisinopril 5mg PO daily

2. ASA 81mg PO daily

3. Metoprolol 25mg PO 2x/daily

4. Simvastatin 40mg PO daily

5. Augmentin 875mg PO 2x/day x7d, to complete on Feb 09 2012

TO-DO LIST :

1. Feb 15 2012 - PCP to follow-up with patient for routine follow-up visit

2. Mar 01 2012 - PCP to repeat Chest X-ray to ensure resolution of pneumonia

3. Apr 01 2012 - PCP to repeat lipid panel and LFTs to monitor Simvastatin dose

4. Apr      2015 - Gastroenterologist to repeat colonoscopy to follow-up benign polyps 

5. Jan       2020 - PCP to give repeat Tetanus vaccination 

SIGNED : __Dirk Stanley, MD_(Hospitalist, Internal Medicine)______ Date : Feb 03, 2012     

                                     

(My apologies to George Lucas - I'm obviously a big fan - Hope you don't mind me using characters to demonstrate this new medical note...!)

Anyway, I think the advantages of this drafted Patient Handoff Note ("Football") are this :

1. It would be a very high-value note that docs would look and ask for (like McDonalds French Fries!) when receiving a patient :)
2. After receiving the football from another physician, it makes creating your local documentation much easier.
3. After receiving the football from another physician, it makes it very easy for you to update the football for the next provider.
4. By making it something all doctors expected, it would drive ownership of the note by all physicians, so...
5. ... It encourages docs to own, review, and continuously update the full med list, problem list, to-do list, allergy list, etc
6. It makes med reconciliation easier for everyone.
7. It could virtually replace notes involved in the expected transfer of care such as the transfer note, overnight coverage signout, discharge note, and consult referral
8. Nicknaming it "The Football" makes it fairly intuitive about its importance and who to push it to and when
9. In a push environment, in an unexpected transfer of care, an ED doc or Hospitalist requesting this from the PCP would pretty much ensure the PCP was notified about the admission in a timely basis.

It's definitely an off-of-the-beaten-path idea, but I'm going to suggest it to my fellow physicians here in Massachusetts, as we start to warm up our state-wide HIE and get it running. Will let you know the results!

Is this note wishful thinking, or just crazy? Always interested in feedback and questions! Send me your thoughts and ideas! Love the discussion just for education's sake!

Cutting Healthcare Costs by Making A Better Brick

1. THE BRICK

An interesting question I get asked is, "Why don't all order sets look the same at every hospital, even for the same disease?"

This question can be posed in several other ways, including :

1. "Why can't we just use order sets from someone else?"
2. "Why can't we just use canned order sets without editing them?"
3. "What do your policies look like?"
4. "Why can't we just use canned policies?"
5. etc...

But all of these basically ask the question, "Why isn't this standard?" and, of course, the follow-up question is, "Why is every hospital re-inventing the wheel?".

For inspiration to answer this question, I'd like to first explain a little bit about a wonderful thing : The brick.

According to the Wikipedia article, bricks have been in use since about 7500 BC to help construct things. (It's actually a really interesting article - If you appreciate human civilization, the brick has played a big role in building our streets, aqueducts, houses, walls, etc...)

The reason the brick is such a useful thing, from a design standpoint, is because it has two features :

1. A brick has a fairly predictable shape that allows you to easily arrange them to connect two or more places in space.
2. A brick is designed to withstand a particular load.

You'll notice these two features are helpful when designing any system - Having basic units engineered in a predictable manner, which can be assembled to make a bigger, more complex system that achieves a certain goal.

Hospitals contain systems that are also made of smaller units - Order sets are made of orders, clinical pathways are made of order sets, charts are made of notes, policy manuals are made of policies, etc. 

Unlike a physical brick, however, all of these basic units are conceptual - They are mostly complex documents - not physical objects - so it's a little harder to tell how predictable they are - e.g. to know if they're not engineered exactly the same.

For example, with physical bricks, it's much easier to tell if one hasn't been engineered exactly the same as the others :

You can immediately and obviously see the entire system is off, and locate the offending brick quickly.

But real bricks are not 100% predictable - They all have some degree of imperfections between them -As a kid, I occasionally ran into bricks behind our grade school, or around landscaping projects - I think I could only stack about 10 of them on top of each other before they start to fall over. (Legos are about the only bricks I can think of that are engineered to such a high standard that you can stack virtually hundreds of them on top of each other and still have practically a straight wall.)

But because regular bricks in the real world have subtle imperfections, humans have developed a tool we can use to compensate for these imperfections : Mortar, or cement.

Mortar/cement only works, however, to help straighten out the system when our brains get involved - We see the system leaning, so we set up guidelines/markers to help determine what is straight, and we put down the mortar/cement to compensate and correct the system. Again, the compensation depends on our human brain.

Because documents are not physical objects, we may not see the system leaning - But it can lean the same way in a conceptual manner. Fortunately, our brains can still compensate for a lot of conceptual leaning. 

So in my job in clinical informatics, I look at the standards by which the "document" bricks are built - To determine just how standard they are, and how much people's brains are compensating.

And this is why hospitals all have order sets that look and behave slightly differently - Because there aren't national standards by which their bricks are engineered. Fortunately, human brains are filling in the mortar.

What would it take to get all hospitals to engineer exactly the same bricks? The same engineering standards at all hospitals. 

And what would it take to get all hospitals to engineer bricks as well as Legos? An engineering process that was detailed enough to ensure that every brick looked virtually identical.

So why don't all hospitals have the same engineering standards and engineering process? Because documents, unlike bricks and Legos, are not as easily understood/studied/observed as physical objects. And because, for better or for worse, human brains can compensate extremely well - So there is little pressure to engineer them exactly the same. 

So as a result : Every hospital is re-inventing the wheel when it comes to their processes and their documents. In almost every hospital, they are looking to achieve exactly the same goal (in brick terms, "bear the same load") - Delivering standardized but customizable, evidence-based, high-quality care. But because the engineering standards and processes are not defined nationally, their tools are all ever-so-slightly different, and so virtually every hospital has to engineer them slightly differently.

2. A NEW IDEA ON CUTTING HEALTHCARE COSTS

The number of people employed to re-engineer all of these tools is remarkable. And it doesn't just include order sets - It includes every document in a hospital, virtually everything I mentioned in the CMIO's Checklist - Order sets, policies, protocols, documentation/forms, templates, etc. And all of these tools have to be continuously updated to reflect best practices, new technology, new evidence, etc.

These operations have become part of the price of healthcare - Continuously re-engineering all of these tools, so that the front-line doctors and nurses have the best and most up-to-date :

• Policies and Procedures to learn from and operate by
• Orders to take care of patients and deliver care
• Order sets to standardize and expedite the ordering process for a common clinical scenario
• Clinical Pathways to standardize care for a common clinical diagnosis
• Protocols to standardize and automate care for a common clinical scenario
• Guidelines to help standardize outcomes for a common clinical scenario
• Documentation tools to record and transmit data about care, and guide their thinking
• Templates to help them standardize and expedite the documentation process
• etc...

Unfortunately, keeping up with all of this information, and managing it, is very challenging for most hospitals. The professional industry term for this is "document management", and hospitals that do this well will probably have an easier time in the next five years than hospitals that do this poorly.

So to help hospitals struggling with this, I have often wondered why nobody publishes national, standard definitions of these tools, so that we could at least have the same engineering standards, and maybe then the same engineering processes - So that the order sets would all look the same - And you could truly use the same order set at any hospital...?

I suspect the reason that no regulatory body currently wants to offer these standard definitions is this : Anyone who tries to introduce these definitions and engineering standards nationally will have a big operational and financial challenge : 99% of hospitals would suddenly have to re-tool all of their documents to meet these national standards. Imagine the cost to healthcare nationally.

But so then I wondered - could we do something like this on a much smaller basis, in a much slower, more controlled manner?

Again I'll mention our Interstate 91 Informatics project - Where a bunch of volunteer Informaticists along the Interstate 91 Corridor here in New England are starting to meet regularly to talk about our common informatics issues. As I mentioned in a previous post ("Can we do better than SOAP?"), we are going to start talking about ways to standardize our documentation on a regional level. I'm interested to hear people's responses because it could be very interesting if, in the next step, we looked at standardizing our definitions, engineering processes, and engineering standards. Would it allow us to share resources that ultimately saved all of our hospitals money, and reduced the cost of operations and care in the entire region?

Stay tuned!

My belief is that we are all both teachers and students our entire lives - So I love to hear people's feedback and thoughts. Feel free to leave comments or questions - Always glad to entertain any new or interesting ideas!

Rethinking Prescription Writing Standards (SIG)

So I train a lot of doctors on electronic medical records. I'm always interested to learn how doctors think about their medication orders. How do they write them? Do they understand them? Do they know who reads them? How does that order get to the patient?

One of the areas of prescription writing I'm particularly interested in is the SIG: section of a prescription. (For some of the basics of a prescription, see this excellent Wikipedia article.)

"SIG" is medical shorthand for "Signa", which in Latin literally means, "write". In simple english, it basically means, "Please write these instructions for taking the medication : _________________"

(Huh? Why not just write "Instructions : _____________" - I mean, don't we have printed pads? Is ink too expensive?)

Anyway, some examples of "SIG:" shorthand commonly seen on prescriptions include :

SIG : 2 tabs PO q6h prn   (IN ENGLISH : Two tablets by mouth every six hours as needed)

SIG : 40 mg PO BID  (IN ENGLISH : Forty milligrams by mouth twice daily)

SIG : 1 patch TD daily (IN ENGLISH : 1 patch topically daily)

Why do doctors write this bizarre latin shorthand? I'm not sure, but it sure is short to write. For more details on this medical shorthand, Wikipedia has this article on prescription shorthand - Some of these I'm not even familiar with as a practicing physician.

Does this shorthand help patients understand how they're supposed to take their medications? Not really. So we need pharmacists and nurses and other health professionals who help interpret this.

As a linguist, I'm also puzzled - Here we have a writing that allows communication from doctor to pharmacist, and doctor to nurse, but not doctor to patient. Why does this language exist?

One of the more fascinating parts about this communication is that here seems to be some confusion about "BID", "TID", "QID", etc. versus q12h, q8h, and q6h.

First, some background about this :

1. QD - In Latin : Quaque Die - In English : means "Once a day"
2. BID - In Latin : Bis In Die - In English : means "Twice a day"
3. TID - In Latin : Ter In Die - In English : means "Three times a day"
4. QID - In Latin : Quater In Die - In English : means "Four times a day"

These are so pleasant, and potentially difficult to read (depending on handwriting), that they are falling out of favor and being replaced with their English equivalents.

Then, there is the q___{time} designation, like :

1. q2h = Every 2 hours
2. q4h = Every 4 hours
3. q6h = Every 6 hours
4. q8h = Every 8 hours
5. q12h = Every 12 hours
6. q24h = Every 24 hours
7. q48h = Every 48 hours

What I find interesting is the common question, "Should I write this medication QID or q6h?"

I. THE DIFFERENCE BETWEEN QID AND Q6H

Ever heard of the story of the patient who asks the pharmacist, "My doctor says I should take this medication four times a day - Does that mean I need to wake up in the middle of the night to take it?"

What this speaks to is some confusion about the difference between the two. Often, doctors use the two interchangeably. But while in most patients the clinical difference is minimal, they are very different to nurses and pharmacists. Here it is :

QD, BID, TID, and QID actually have very specific times attached to them.

1. QD = usually 08:00am
2. BID = usually 08:00am and 20:00pm
3. TID = usually 08:00am and 12:00noon and 20:00pm
4. QID = usually 08:00am and 13:00pm and17:00pm and 22:00pm

When I say usually, I mean it - Many hospitals have slight variations to this schedule. As an example of how challenging this can be, some hospitals publish their own standard medication timing guidelines like this which try to help standardize these times. Ask your hospital pharmacy what their standard med administration times are!

The one thing that is pretty standard about all of these (QD, BID, TID, QID) in virtually all hospitals is that, as much as they might vary, they're all usually during waking hours. None of them would technically let you take a dose at 4am.

q2h, q4h, q6h, q8h, q12h - DO NOT have specific times attached to them.

In other words, if you write to give a medication every 12 hours, the actual time it will be given will depend on what time you write the order : If you write it at 5am, then the medication will be given at 5am and 5pm. If you write it at 7am, then the medication will be given at 7am and 7pm.

Of course, if you wanted it to be given at 8am and 8pm, but you were writing the order at 5am, then you could write "q12h START TIME : 08:00am" 

This is why it's not uncommon to see as-needed pain medications written as "TID PRN" - Many doctors are not even totally aware of the difference between TID and q8h. Of course, in most of these instances, if a patient were to go to the doctor and ask "Can I take it at 4am for pain if I need to?", the doctor would often say "yes".

Clear as mud? The good news is that with most medications, being an hour or two off means little in terms of the amount of drug in the blood - So it really doesn't make much difference from a clinical perspective. 

But this language sure causes some confusion. Do we really need this Latin shorthand? Who is it helping?

II. RETHINKING THE SIG

So today at work, I was rethinking the sig :

And it's interesting - I noticed that in about 90% of prescriptions :

1. PRN (as needed) medications : Often use q____h PRN _________________
2. Standing (regular) medications : Often use QD, BID, TID, QID

This makes sense - Generally, docs don't want their patients waking up regularly to take medications at 3:00am.

So I wondered : Could we leverage this pattern to help with electronic order entry?

And then I wondered : Instead of this alternate, Latin-based language which allows doctor-to-nurse and doctor-to-pharmacist communication, but no doctor-to-patient communication ...

could we make a language that everyone (doctor, patient, pharmacist, and nurse) understood equally well?

III. THE COGNITIVE FRAMEWORK :

It seems the real division is between regular (every day) medications and PRN (as needed) medications.

As I mentioned :

1. EVERY DAY (REGULAR) : COMMONLY USE QD, BID, TID, QID
2. AS NEEDED (PRN) : COMMONLY USE Q___h PRN ____________

So could we use this to shorten the length of options commonly seen in EMRs for medication frequencies?

And then when doctors, nurses, and hospitals are trying to collect medication histories with the simplest, smallest number of clicks, instead of thinking of :

[ Medication Name ] [ Dose ] [ Route ] [ FREQUENCY ] [ PRN ] [ REASON ] 

could we instead cognitively think about medication orders like this :

[ Medication Name ] [ Dose ] [ Route ] [ PRN ] [ FREQUENCY ] [ REASON ] 

???

This would allow us to re-consider, re-evaluate, and redesign our forms!

IV. THE SAMPLE SCREENS :

And so a draft paper form could potentially look something like this :

And this would allow us to set up the electronic documentation of a single medication according to this form where you could "just click on options" :

And so for about 95% of medications, this would allow you to enter medications very easily! For example, Lasix 40mg PO BID could instead be : ("Lasix 40mg" + 3 clicks)

Or Percocet 5/325mg PO q6h PRN moderate pain (4-6) could be : ("Percocet 5/325mg" + 2 clicks + "moderate pain") :

"

Or one could even expand the PRN reasons, to turn that same percocet order into "Percocet 5/325mg" + 3 clicks) :

and this could be a form that physician, pharmacist, nurse, and patient could easily comprehend to all speak the same language.

It also guides a physician to avoiding the small issue of "Percocet 5/325mg PO TID PRN mild pain".

And for those other 5% of medications where either there are unique medication times, or when you absolutely need the patient to take the medication every 6 hours and start at 03:00am, you could still click the "FOR OTHER INSTRUCTIONS" box all the way at the right.

I just thought I would share some ideas of how you can help fix your med reconciliation forms and possibly your med reconciliation EMR software, to promote clarity and help reduce clicks. Who knew medical informatics could be so much fun!

Would love comments! Anyone have any other thoughts about the subject? As always, education is a priority, and discussion is welcome!

Van Halen and why Informatics is not IT

One of the things you get asked commonly, when you work in informatics is, "Are you an IT guy/gal?"

Informatics is commonly confused with IT (Information Technology). But the two are very different. Allow me to explain.

Definitions about informatics vary widely, but I personally take the everyman's, common, "Ernest and Julio Gallo"-type approach - It shouldn't be something that's scary, unapproachable, or unaffordable. I hope to deliver good informatics to your dinner table at a reasonable price in a way that everyone can enjoy. So when I had the opportunity to help, I added the part about "right information to the right person in the right place at the right time in the right way" to the definition in the Wikipedia article on informatics (academic field). Just sounds so much simpler, approachable, and friendly.

This definition still won't make sense to many people, but I'll say this : Informatics may have nothing at all to do with computers. Yes, often informaticists often use computers in their jobs (while planning to save the world!), but some of my favorite examples of informatics have nothing to do with computers.

1. THE FIRST EXAMPLE
The first example of informatics without IT comes from a business professor I had back in college, who did informatics consulting for businesses. He told us this story of a large, popular European furniture company with a quality problem they were having.

The issue, he said, was this : The company had a table they were selling which was often getting returned. Why? "MISSING HARDWARE!" was the most common reason reported by unsatisfied customers.

The company had tried several times to fix the problem on their assembly line, to no avail. Despite their best efforts to remind workers to put all the right pieces in the box, the workers still sometimes forgot.
So reportedly this informatics consulting company examined the assembly line closely :

They focused on Worker #4, who apparently was in the area where the problem arose. His task was to take the Type A bolts out of bag A, the type B bolts out of bag B, and the Type C screws out of bag C, and put them all in the box. But when they studied him, they noticed : He was occasionally forgetting to put in the Type A bolts, occasionally forgetting the Type B bolts, and occasionally forgetting the Type C Screws.

The trick was to get him to remember to put in all three types, every time.

How to do this? They looked to establish something informaticists generally call "cognitive feedback" or "visual feedback" - Where a person gets some immediate feedback/verification of, "Have I done the job right?". And they found the solution in the factory lunchroom, where reportedly the lunch trays just happened to have three pockets in them :

Using a magic marker, they labeled each pocket with an A, B, and C, to create a tool to provide the factory worker with cognitive feedback during his part of the assembly line.

So now instead of taking from bag A and putting it in the box, bag B and putting it in the box, and bag C and putting it in the box - They told him to put from bag A into the tray, bag B into the tray, and bag C into the tray :

Voila! This provided immediate visual feedback/confirmation to the worker that "Yes, you have remembered all three", allowing him to then dump the tray into the box, knowing the task had been completed properly.

And as the story goes, after this change, their quality problems disappeared. All for the price of a $4 lunch tray. The table reportedly ended up being a big hit.

2. THE SECOND EXAMPLE
The second example of Informatics without IT was given to me by the same college professor, who used to do informatics consulting. He was hired to study the waiting times at a large fast-food burger chain. Their issue : "We are losing customers, and can't figure out why." Customers told the chain : "Service is too slow", and no matter what the company was doing to speed up operations, they were losing customers.

This business professor gave me some good informatics advice that still sticks with me today : "The first trick to knowing how to fix a system is knowing how to crash it. Once you know how to crash the system, you'll know how to fix it."

So apparently he and his buddies spent a whole week trying to crash one of this burger joint's restaurants.

1. They tried spilling food in the middle of the restaurant. No go - Someone came and cleaned it up.
2. They tried yelling really loud and carrying on. Didn't work. The workers called the police and they were escorted out.
3. They tried ordering very slowly at the counter. Didn't work. Another cashier opened up and the line moved along.

Then they paid very close attention to the crowd during lunch, and heard someone take advantage of the resaurant's jingle at the time : "Hold the pickles, hold the lettuce, special orders don't upset us." The order they heard? 

"Um, I'll have a double cheeseburger, extra-well-done, with extra lettuce, no tomatoes, no onions, ketchup but no mustard, extra pickles." 

The restaurant handled this order just fine, but his team noticed that if the person said the order loud enough, during a busy lunch crowd, suddenly everyone else wanted their burger done their way.

So they tried it out the next day, during a busy lunch hour : Two or three of his team ordered their custom burgers, loud enough that people towards the back of the line could hear. It set off a chain reaction that slowed the restaurant to the point where the line went out the door. Customers left in frustration.

Their advice to the restaurant : Lose the jingle. It's OK to allow customers to do custom orders, but if you advertise it, you're only asking for trouble.

So they got rid of the jingle, and reportedly the waiting time went down, and satisfaction went up.

3. THE THIRD EXAMPLE (ROCK & ROLL!)
The third example comes from popular rock and roll culture. Ever heard of the 1980s-1990s rock band, Van Halen?

                                                               Van Halen : Informatics Pioneers?

Ever heard of the popular mythology of their concert contract demanding they have no brown M&Ms in their dressing room? As a child of the 80s, I remember hearing about this - It became a little joke of rock-n-roll culture, even parodied in movies like Wayne's World when Wayne gets to walk backstage at the Alice Cooper concert. It's the inside joke of roadies and concertgoers everywhere.

Get ready - It's not a myth! TheSmokingGun.com even has an actual copy of the Van Halen contract rider, which you can read by clicking here. But rather than just juvenile rock-star excess, both TheSmokingGun and Snopes.com go on to explain the real purpose of this request :

The issue was that the band was touring with some very hefty equipment : Large light shows, elaborate sets and music, etc - And there were a lot of technical errors happening. The girders couldn't support the weight of the sets. The flooring would sink in. And despite their contract having very clear instructions of what it would take for the band to perform safely, it seemed people weren't reading the contracts fully.

So by adding the clause :

"Article 126 : There will be no brown M&Ms in the backstage area, upon pain of forfeiture of the show, with full compensation."

it allowed the band to quickly determine if the contract had been read in detail, to give them some confidence that all of the technical specifications had been met.

In other words : They had immediate cognitive/visual feedback about the adherence to the contract and performance of the safety design. An easy way to see failure before it happened!

What genius! (I know David Lee Roth later became an EMT - I wonder if he's involved in HealthIT today?)

So ask yourself : What are your brown M&Ms, and can they help your safety discussions?

It's all about getting the right information, to the right person, in the right place, at the right time, in the right way - Doesn't necessarily have anything to do with computers at all. And hopefully by doing that, you'll help save the world. (Or at least make it a little better place to live.) :)

Again, I always welcome comments! Feel free to leave thoughts or ask questions - I'm always glad to ponder the imponderable!

Rethinking electronic documentation filters

"Life is a series of hellos and goodbyes, I'm afraid it's time for goodbye again..."
- Billy Joel, Songs in the Attic, 1981

So I was thinking more about the challenges with electronic documentation. As I mentioned in my last post, I'm thrilled that people are going to be seeking ways to transmit notes to each other, but I'm just not convinced we have agreement about *what* to send and *when*.

The problem is that healthcare reform is going to center around documentation. So documentation is going to become more important than ever. Knowing :

1. What and when to document - and...
2. How to find the right information quickly

... is becoming a key survival skill for hospitals and doctor's offices.

So for today, I wanted to ponder #2 above - (I'm going to ponder on #1 in my next post...)

As part of my job, I teach docs about how-to-find-the-information-they're-looking for. Most EMR software has some system of "filters" you use to narrow down your search to exactly what-you-need.

Sometimes those filters, and learning to use them, can be a little complex, and it's not always the most intuitive. So I wondered - How can we make it more intuitive? I wondered how *I* would graphically re-think a chart - If the chart is all about a patient's life, then why not start with a simple timeline?

(Of course, since we don't really ever know when the end will be, we can just assume the line will have "TODAY" listed on the other side from "START".)

Anyway, during our lifetimes we will all have interactions with people - That's what we want to record. The goal of the medical chart is to document all those interactions.

Some relationships will last for varying lengths of time, all generally starting with a "HELLO" and a "GOODBYE".

It's funny - I think as human beings, our brains tend to remember the "Hellos" and "Goodbyes" much more than we remember the stuff in-between. Anyway, in clinical terms, that "HELLO" is either an "Admission H&P", an "Intake Note", or some sort of a "Primary Evaluation" - And the "GOODBYE" is a "Discharge Summary", "Transfer Note", or some other type of "Signoff Note"  :

But of course, if you're following that person regularly, you check in from time-to-time throughout the duration of your relationship. In "best-friend" terms, that's a "stop-by-for-a-visit" or "chat on Facebook". But in clinical terms, these "check-ins" are your progress notes :

The challenge then in documenting your life is that you will have to manage the information about these sorts of ongoing relationships for many people in your life :

And so if they all have an Admission-type note, several progress notes, and a discharge-type note - You already have a large amount of data to keep track of.

And making things more complex is that other people in your life will only be brief but still-important encounters - The cashier you met while withdrawing money while on vacation, the dermatologist you saw once to burn off a wart... Some of the people you interact with in your life will just be single encounters :

Finally, I think it's also important, when re-thinking the medical record, to remember that a patient's life will be punctuated by changes in level-of-care. As long as you have some kind of health coverage, you will always be in one level-of-care or another. (It's even debatable - If you have no insurance, could you still be in an "outpatient setting"? Deep philosophical questions for the healthcare informaticist!) So if we look at the patient's life from this level-of-care perspective, there are definite punctuations which are immediately useful at understanding clinical activities in time :

And so, whoever tries to comprehensively document the life of a patient will have a very complex issue to untangle - Who documented what, and when? :

Fortunately, I think most people think intuitively when inquiring about a patient's life - You either want the whole story, or a part of it. And how much you ask for will depend on your need. Want to admit them for a psychiatric admission? You might be interested in their first childhood pediatric notes. Have a "frequent flyer" you know well? You might just want the notes from the last few levels-of-care. And with computers, it's fairly easy to draw a box over the time period and notes (colors) you want :

Of course, this is somewhat of a jumbled mess - But if the user could help arrange the order of the colors they wanted, they could sort out the mess (by their own individual preference), and then by dragging one box :

... you could quickly select :

1. The timeframe you need (X-axis)
2. The notes you need, by your general and immediate preference (Y-axis)

Of course, the colored lines above make it sort of complicated (would some users interpret this to mean the patient had all of these people in their lives throughout the duration of time?), so maybe you would prefer to be able to check off the notes (by profession) you want, as you make your query for documentation :

... and so in this way, you could quickly get to the notes you want - In time, using levels-of-care as a marker, and by specialty. (But remember a common problem with electronic documentation : Sometimes you WANT the doc to see "REALLY IMPORTANT" stuff from a specialty they didn't think to look for, e.g. Case Management, physical therapy, chaplain services - In the paper world, those "REALLY IMPORTANT" things were usually done as a "sticker on the chart" or something like that... It's a little trickier to do that sort of thing with an electronic chart. Who gets to decide what's "REALLY IMPORTANT"?)

OF COURSE, making this sort of a search filter available for your own medical record would depends on some of the following factors :

1. Having a common (or at least steady) patient identifier, so that someone will be able to assemble all the documentation from all of these different clinical people you interact with.
2. The ability to mark documentation with not only the author, but the profession/specialty they represent.
3. Being able to mark changes in level of care across a healthcare delivery system.

... so I'm not counting on seeing this in any software tomorrow - But I think it's potentially another way to look at the mass of information about a patient and quickly get what you want in an intuitive way.

REMEMBER : WITH FREE OPINIONS, YOU GET WHAT YOU PAY FOR. :) Always glad to hear from people - Feel free to leave thoughts and comments! :) In my next post, I'm going to ponder about "How much documentation is enough?" - Stay tuned! :)

Can we do better than SOAP?

So I've recently been looking at some of the most important standards we have, that few people appreciate. Some standards that I've recently been admiring the beauty of :

1. The 110-volt AC plug in America - Thank goodness for this! Imagine if you had to worry about which coffee maker you could or couldn't buy because it didn't have a plug that fit your house! (Or even better, think about how challenging it is to travel with that same coffee maker to a different country!)
2. Traffic lights - Thankfully, they all behave the same in our country. Imagine if driving from Maine to Florida meant having to learn different traffic signal patterns?
3. Traffic patterns - We all drive on the right side of the road in the U.S. - Imagine having to change as you drove state-to-state? (I wonder how they handle this in the Chunnel between France and England?)
4. Train tracks - Snopes.com has this interesting debunking about railroad gauge, that includes a mention of how during the American Civil War, the northern railroads had one gauge while southern railroads had multiple gauges -  this was argued by historian James McPherson to be one of the logistical factors that contributed to the Union army winning over the Confederate army. (And interestingly, after the North won the war, many of the southern railroads were rebuilt by the North, giving us the American standard of 4 feet, 8.5 inches.
5. The Apple iPhone/iPad/iPod charger - Although Apple toyed with some of the charging pins since the iPhone 3G, the plug has essentially been the same since the original iPod in 2001. Now it seems that since the iPhone 3G, you can use the same plug to charge your iPhone 3G, iPhone 4, iPhone 4S, iPad, iPad2, iPod Touch, and various other apple devices. I suspect this is why the plugs are becoming so ubiquitous that most of my friends now seem to have one in the kitchen just to let visitors charge their Apple devices.
6. American Standard Code for Information Interchange (ASCII) - This is arguably much larger than just an American standard - Although Unicode has expanded the ability for designing documents, ASCII is probably the most widely-used standard in computing.  Can you imagine if your processor didn't know you pressed the "A" key on your keyboard? What if that "A" didn't show up on the screen? What if you sent an email and the "A" didn't arrive?
7. Internet Protocol (yes, both versions 4 and 6) - The Internet would not be possible without a standard Internet Protocol. 

So I think we can all agree that these standards are good for us - And thankfully for healthcare, the ANSI (American National Standards Institute) created a new HITSP chapter in 2005 after the ONC recommended someone start working on healthcare IT standards. (A shout out and thanks to John Halamka, MD for taking on this labor of love!) :)

Anyway, I think the take-home message about healthcare IT standards is that we're still really early in the process. (As of this writing, the HITSP has only been around for about 6 years!)

So because a lot of my work as an informaticist deals with the struggles to achieve standards, I think a lot about the final objective of informatics : Getting the right information to the right person in the right place at the right time in the right way. (It's easy to get 2 or 3 of those right, but getting all 5 right is much more difficult.)

Anyway, so it's nor surprising that I eagerly await the day when the Regional Extension Centers (RECs) and Implementation and Optimization Organizations (IOOs) finally make the HIEs that smoothly link our electronic medical records - ... But what then?

A WORD ABOUT STANDARDS FOR CLINICAL DOCUMENTATION

In my quest to get the right information to the right person in the right place at the right time in the right way, it dawns upon me that the best technical solutions may still fall short of expectations because of this : There aren't really any good standards for the content of electronic documentation.

In fact, I started to ponder - What standards are there, at all, for clinical documentation?

Most practicing physicians can pretty quickly think of one real standard - The SOAP note. It stands for "Subjective, Objective, Assessment, and Plan", and is a rough outline for how you write a note in a logical way :

S - Subjective - What you heard from the patient (history, opinions, and answers)
O - Objective - What you saw about the patient (measurable things or physical findings)
A - Assessment - What you believe is currently going on with your patient
P - Plan - What you and your patient are going to do about it

The SOAP note is also a cognitive framework for how we think and communicate about patients - When you sign out to another physician, the SOAP note influences our thinking and what we say or write about our patients. By forcing a physician to confront the evidence (S, O) before rendering an opinion (A) and plan (P), it has had a remarkable impact in improving the quality of care and communication about that care.

Interestingly, the history of the SOAP note goes back to this seminal paper written by Dr. Lawrence Weed, published in the March 14th, 1968 edition of the New England Journal of Medicine. (Click on the link above to read the actual article.) 

** IF YOU WORK IN HEALTH INFORMATICS, YOU SHOULD READ THE ORIGINAL ARTICLE IN ITS ENTIRETY. **

One of the fascinating parts about this article is in its opening paragraphs - The purpose of this paper, in 1968, was "...to develop a more organized approach to the medical record, a more rational acceptance and use of paramedical personnel and a more positive attitude about the computer in medicine." Snark Alert : Amazing how far we've come in the last 43 years!

But getting back to serious discussion, the paper highlights many of the struggles we have had with implementing EMRs in the last 40 years - And still continue to struggle with today. When you read the article and see how notes were structured BEFORE the SOAP structure, you can see why some people argue he should win a Nobel Prize for Medicine. 

It's also good to know Dr. Weed is still developing his argument, as published in this 1997 British Medical Journal article. (THANK YOU DR. WEED!)

But then I thought : We have the SOAP note - But do we have anything else to help guide us?

Since most medical schools teach little about clinical documentation (you're usually too busy learning about diseases), many doctors finally learn about note writing from pocket books like the Washington Manual Intern Survival Guide. (Similarly-themed but shorter "Intern Survival Guides" can be found here and here, just to get an idea of what I'm talking about.)

So if most of our education for physicians about writing notes falls down to these pocket guides, and the notes are often specialty-dependent but built on the SOAP framework - It's no wonder we all struggle with electronic documentation.

A WORD ABOUT THE STRUGGLES OF ELECTRONIC DOCUMENTATION

Anyone who has worked on electronic documentation will tell you : It's hard to build, and hard to maintain.

The first challenge is getting a note built - What exactly will you use the note for? What will you name it? What do you want to include in the note?

Looking for answers to these questions often depends on :

1. The planned clinical scenario
2. The physician's experience
3. The physician's pocket guide they learned from in Internship
4. Regulatory and compliance issues (the stuff that insurers and other regulators want to read about)

The funny thing is, every hospital is working on this same problem separately - Often coming out with similar but slightly different results. It's a great example of "everyone rebuilding the wheel".

Why can't all Medicine History and Physicals look the same? In my experience, most of them approximate the same SOAP format, but I've even heard the argument, "I'd like to see the Plan at the TOP of the note when I read it." This speaks to a challenge of documentation in general - 

1. Documentation is closely tied with our cognitive processes.
2. Our cognitive processes, while similar, are not entirely standardized.
3. Regulations, insurer demands, and clinical practices change frequently, making it important to maintain notes after they're built.

So in the end, clinical documentation is more expensive to build and maintain than most people imagine - And every hospital is having the same struggles together.

And because the notes may vary in their end result - An electronic note sent from a doc in one hospital one day may not have the best reception by the physician at another hospital.

In other words : I'm thrilled we're working to link our EMRs - But will the notes we send be equally effective at another hospital?

THE INTERSTATE-91 INFORMATICS PROJECT

So we have a new, small, informal group of volunteer healthcare informaticists here along the Interstate 91 Corridor that stretches between New Hampshire/Vermont, all the way down through Massachusetts to New Haven, CT. We meet informally every 3-4 months for dinner to discuss healthcare informatics, and I'm glad to report we recently obtained a donated website, which we hope to develop. 

I'm hoping at our next dinner to propose a few crazy ideas to our group : 

1. What if all of our documentation looked the same? (for the same clinical scenario...)
2. Could all of our clinical documentation look the same? (for the same clinical scenario...)
3. Could we develop a standard for content of electronic documentation?
4. Could we help further develop the SOAP note, to provide a logical and cognitive standard that helps improve care and reduce costs for all of us?
5. Could this framework be used as a teaching tool about clinical documentation in medical schools and residency programs?

Will let you know how things turn out after our next dinner. Look out for the I91 Standards. :) (Ooh, another cliffhanger, I know!)

As always, I love to answer questions. Feel free to respond with thoughts, questions, ideas, or other discussions. Remember : Education is a priority! :)