A Book Review for HealthIT Communicators

My wife works at a library, and often brings home books she enjoys reading.  Recently she told me about a book she was reading by Alan Alda about the work he was doing with Improvisation and communication in Science and Technology.  I grabbed a digital copy for the family including the audio-book version read by Alan.

So much of this book resonated with my experiences over that last decade+, starting with the event that gave me the reason behind the name of this blog.

Many years ago, I found myself speaking to an audience with a slide deck in front of me, behind a podium 20 feet from the front of a raised stage, in an auditorium with an orchestra pit.  After 15 seconds of trying to connect with the audience in that awkward postion, I ditched the podium mike, grabbed the hand-held and went to the front of the stage. 

I was now back in a familiar setting, that of the theater, in which I had spent some three semesters with a fantastic director from my early college days.  And I responded to that setting with all of the training* I had been provided about speaking (projection, diction), connecting with audiences, and MOST of all, improvisation.  First thing I did was went off script**.

I used that entire stage as I talked (from down stage right) about how Cross Enterprise Document Sharing (XDS) would enable patients living and being cared for in Hartford (where we were meeting) who traveled to Danbury (crossing to stage left) get access to their documents, traversing back to the center to reference my slides on the large backlit projection screen behind me (somewhat like a TED setup).  I could see the audience track me with their eyes from one side of the stage to the other.

That presentation was a turning point in my career in terms of how I approached speaking at public events. What I learned on that day was what Shakespeare already knew: "All the world is a stage, and all the men and women are merely players ..."  Since then, I no longer need the trappings of the stage, merely the impression that I have one, to apply that training I so thoroughly enjoyed.  Improv was the key for me, as it was for Alan as he describes in his book.

This is an awesome book for technology communicators. Read it. Enjoy it. Apply it.  I have the same sense about this book as others related to me about my presentation that day.  He nailed it.

   Keith

* For those of you who don't know me well, I am somewhat of an introvert.  Dealing with people in groups is exhausting, and I can spend hours on my own quite satisfied.  But I loved theater because it was a safe environment to go be other than my introverted self.  So I explain myself as being a well-trained introvert, and it was that early theater and improv training I had in high-school and college that I'm speaking of.

** I no longer script presentations, but I do prepare and rehearse them, especially if I've only done them once or twice.

Will Faxes never Die?

A very old fax machine

A question comes to me from a former colleague that I found interesting:

Can you convert a fax document into a CCDA for Direct Messaging?

Yes.  Here's how, at three different levels of quality:

Unstructured Document

This is the simplest method, but it won't meet requirements for 2014 or 2015 Certification.  It's still somewhat useful.

1. Convert the image into a bitmap file format such as PDF or PNG.
2. Create a CCDA Unstructured Document.  Optionally, apply the IHE Scanned Document requirements to the content as well.
3. Include the document into a Direct Message

Getting to Electronic Text

Getting the content to meet 2014 or 2015 requirements for certification means doing quite a bit of additional work.  First step is to get to electronic text.

1. First, you have to apply text recognition technology to the output to turn it into electronic text.  This converts the image content into letters and symbols that the computer can recongize.
2. From this, create a bare-bones narrative structure with headings and section content.  Apply some very basic Natural Language Processing (NLP) to recognize headings and section content.  Signals such as line spacing, paragraph formatting and font styles are helpful here (that would often be included in a more than basic text recognition pass).  From here, you could create a Level 2 CDA (note, NOT a C-CDA yet) that would be MORE useful to the receiver.

Getting to Certification

After getting to electronic text, now you need to get to CCDA Entries.  It can be done, I've been there and done that more than a decade ago.

1. From the previous step now you need to code the section headings to LOINC, and match the document content to an appropriate C-CDA template (knowing that you can also mix and match sections from other C-CDA documents into the base C-CDA CCD requirements).  At this point, you are at level 2 with coded sections.
2. So finally, you need to run some specialized NLP to recognize things like problems, medications, allergies, et cetera ... and THEN
3. Convert the specialized content to match the C-CDA template chosen in step 3.

And now, you COULD meet 2014 or 2015 Certification requirements.

Would I do this?

The question not asked, but which I will answer is:

Would you convert a fax document into a CCDA for Direct Messaging?

Probably not, AND certainly not for the structured content option.  Current NLP algorithms being what they are, you could probably get to about 95%  accuracy with the structured markup, which means about 1 error in 20 items.  That's MULTIPLE structure recognition errors per page, NOT a level of accuracy appropriate for patient care. The level of effort involved in cleaning up someone else's data is huge, the value obtained from it is very rarely worth the cost.  You are better off figuring out how to give your high volume fax senders a way to send you something better.

I might consider implementing the Unstructured Document mechanism as a feature for providers that are getting faxed today, as many would find it of some use.  It's not really much more though than giving them an e-mail end-point attached to a fax number, so again, of very little additional value.

Sweat the Small Stuff

Small things can sometimes make a big difference.  The difference between an adequate piece of equipment and an excellent one can be huge.  Sometimes the things that you need to change aren't your equipment, but rather yourself.  That's more than just money, it's time and effort.  It's hard.  It's annoying.

The way that small things can make a big difference is when they provide a small but consistent improvement in what you do.  Keyboards for example.  Today I had to switch back to a crappy backup keyboard because the 5 and 7* keys on my Unicomp keyboard died.  I can already feel the change in my typing speed.  More than half my work is typing, and the better keyboard is the difference between 70 WPM and 75 WPM.  That's a 6.667% difference in speed.  It's small, I can live with it for a short period of time.

What will using the cheaper keyboard cost me?  Well, I don't spend all my typing time at top speed, so really, it only impacts 50% of my work. But, for that 50%, that's the most productive time I have, because the other time is meetings and overhead.  So now I'm losing not just 6.667% of my time, I'm actually missing it out of my most productive activity.

Amortized over a year, that's a whole month of my productive time that I somehow have to make up for.  There goes vacation.  All for lack of a minor improvement.  I'll probably get the Unicomp repaired (it's a great keyboard when it works), but I've got a better one on order with Cherry MX blue switches.  They have a similar feel to the spring-switches in the Unicomp IBM-style switches and are the current "state-of-the-art" for typists as best I can tell.  And if it breaks, I can replace the dang switch, which I cannot do on the Unicomp without about two-three hours of effort.

A colleague and I were talking about how making personal changes can help you in your efforts.  His point was that many cyclists spend hundreds (or even more) to reduce the weight of they bicycles by a few more ounces to get greater hill-climbing speed.  He noted that losing a few pounds of personal weight can have a much greater impact (I'm down nearly 35 lbs since January, but my bike has never had a problem with hill-climbing, so I wouldn't know about that).

Learning to touch type was something I succeeded (if you can call a D success) in doing in high school, but never actually applied (why I got the D) until someone showed me that I was already doing it (but only when I wasn't thinking about it).  After discovering that, over the next six months, I went from being a two finger typist to four, and then to eight, and then to ten.  That simple physical skill has a huge impact on my productivity.

I now make it a point, when I learn a new application to understand how to operate it completely without removing my fingers from the keyboard.  And I train myself to operate the applications I most commonly use to learn them that way because it makes a small difference that adds up.  It's an almost meaningless small thing that greatly improves my productivity.  Yeah, I ****ing hated it when Microsoft changed the keyboard bindings in office (and I still remap to some that I have long familiarity with), but I spent the time to learn the new ones.  It ****ed me off for six months, but afterwards it paid off.

Here's where this starts to come into play in Health IT.  We KNOW that there are efficient and inefficient workflows.  We KNOW that changing workflows is really going to yank people's chains.  How do we get people to make even small changes who want to keep doing things the way they always have been?   And more importantly, what is going to happen to those non-digital-natives who have to adapt to an increasingly more digital world when their up and coming colleagues start having more influence.

When we get rushed, we let the small stuff slip.  It's a little bit more time, a little bit more effort.  And the reward is great and immediate, we get more done.  But the small stuff has value.  It's there to keep us from making mistakes.  Check in your code before the end of the day ... but I'll have to take a later train ... and now your hard drive is dead tomorrow, and you have to redo the day's work.  Which would you rather have?

Sweat it.  It's worth the effort.

So, what small thing are you going to change?  And what big difference will it make?

   Keith

* 7 is pretty darn common in hash tags I use, and in e-mails I write.  That's pretty dang frustrating.