One of the goals of the annual Emergency Department Information Systems Symposium is to educate attendees about those things they need to know to use computers in their EDs intelligently. There are many resources on the web, but sorting through them, and deciding where to start – and where to stop – may be a wee bit problematic.
For two decades now, I’d been giving lectures at various venues on the role of computer technology in medicine, and particularly in emergency medicine, and thus how to talk with computer geeks. For the 2008 14th annual ED Information Systems Symposium, I gave a revised and updated talk specifically aimed at meeting this need. There were various titles in the back of my head:
- Healthcare IT for Dummies
- Healthcare IT for the Uninterested
- Healthcare IT: the Bluffer’s Guide
but finally it ended up being Healthcare IT in a Nutshell.
I prepared an updated and expanded printed handout, which comprises several pages of dictionary/encyclopedia entries, with a couple of sidebars and a few explanatory diagrams. You can print out the handout and read it by itself, which will give you a very basic basic grounding. Or, you can go to the HTML version of the same information, which I will update more frequently, and is easier to browse online.
An Educational Plan
If you are trying to educate yourself about computer systems for your ED, I suggest three-pronged plan for ED IT self-education.
- Learn enough about computer terminology to speak semi-intelligibly to computer geeks (GeekSpeak)
- Learn enough about healthcare IT to be able to speak to CIOs/CTOs (Chief Information Officers/Chief Technology Officers)
- Learn enough about ED-specific IT, so as to be able to speak with everyone, including computer geeks, CIOs, vendors, and your own IT staff about ED issues
If you browse through the HTML version of Healthcare IT in a Nutshell, just reading the text (as well as the two linked pages on EHR vs EMR vs PHR and Standards), you will get a basic grounding in geekspeak, CIOspeak, and EDIT-speak. If you click on all the links to read more on each of the topics, you will get a really pretty-solid education on at least the language of Healthcare IT. (But don’t read all of each linked page – Wikipedia in particular has such detailed information on many of the topics that it will cause brain-burn.)
As Francis Bacon said, We are more likely to reach truth through error than through confusion. So, I’ve tried to (some might say grossly over- ) simplify things.
A few notes before you dive into this project.
First, to talk with computer geeks (call the real hardcore ones “coders”), you need to understand them. (Perhaps I should say “us,” as I learned to program a Z80 CPU in machine code, and only then moved to A86 assembler. I also own five different kinds of soldering iron.)
Did you ever see the old movie Airplane? And in particular the bit where the woman says “it’s OK, I speak Jive, I can translate”? Coders are much the same, speaking only coder-speak.
Have you heard this story?
A man is flying in a small airplane and is lost in the clouds. He descends until he spots an office building and yells to a man in an open window, “Where am I?” The man replies, “You are in an airplane about 100 feet above the ground.” The pilot immediately turns to the proper course, spots the airport and lands. His astonished passenger asks how the pilot figured out which way to go. The pilot replies, “The answer the man gave me was completely correct and factual, yet it was no help whatsoever, so I knew immediately he was a software engineer who worked for Microsoft and I know where Microsoft’s building is in relation to the airport.”
Alan Cooper, in The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity, opines that programmers (“coders” in geekspeak) are a different species: Homo Logicus.
He quotes Robert X Cringely’s book 1992 book Accidental Empires: How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can’t Get a Date, which basically says: Coders are stinking gods among men referring to hygiene and ability to code. They view the world through ability- to-code glasses. If you can’t code, you’re not human, or at least you’re not homo logicus, the only species that really matters. Coders make fun of people who aren’t as smart as they are (pretty much everyone) and respect only people who are their equals or betters in coding. Cooper says coders are jocks: they are proud of their intellectual muscles and use them to twit lesser beings who don’t measure up.
In self-protection, you can learn enough coder-speak to be regarded as at least one of the higher animals, worthy of at least minor respect, as opposed to all those other human vegetables out there.
Long ago, I worked at a hospital that, for its first real Emergency Department computer program, bought and installed the old DOS Logicare discharge instructions program. It was great, in fact one of the best pieces of medical software ever written.
I suspect one of the reasons DOS Logicare was so good was the constraints faced by Dave Elvig, the original programmer. This was a DOS text-mode application. It could only use the ASCII letters, numbers and symbols, including a few simple symbols for lines. The screen could only show 80 of these characters across the screen, and 25 rows down the screen. Not much room! So Dave had to really focus on what was vital to the program’s functioning, and leave everything else out. The program was quite simple, with low cognitive friction, and one could easily form a mental model of how it operated. The left showed a scrolling page of instructions, and the right had buttons with text labels for the main functions of generating discharge instructions. Clicking a button with the mouse, or typing the Alt-key (for instance, Alt-I to see a list of illnesses) would bring up an alphabetical list of the appropriate items. you could scroll with the mouse, or start typing until you found the illness you wanted, and then click or press Enter to enter the instructions in the text to the left. Simple. Elegant.
DOS Logicare passed the sleep-deprived intern usability test:
Take an intern who was on call last night and is starting in the ED this morning. Sit him or her down in front of the computer. Give the intern 30 seconds of orientation about the computer program. If the intern can now use the program effectively and without error, the program passes the test.
The famous composer Igor Stravinsky once wrote a piece of theater/music called The Story of A Soldier. He composed it during World War I, when functioning orchestras were few and far between, so he composed something for a seven instrumentalists and a three actor. He later remarked that the constraints forced him to create what was probably his best work. Similarly, Dave Elvig’s constraints helped him create a masterpiece. BTW, my wife says L’Histoire du Soldat is her favorite piece of music.
Anyway, going back to the main point: DOS Logicare was a great program, but we’d thought of a few ways to make it a little bit better. Dave Elvig came to our ED, and was sitting with his laptop next to our computer as we showed him our thoughts. He thought for a minute, then started typing away on his computer in C++ (I noted it was a UNIX operating system on his laptop) and then recompiled the program, then handed me a floppy with the new program version to try. You don’t get service like that any more! Anyway, I remarked admiringly that he must be a real UNIX wizard (accomplished UNIX programmer) to be able to do this for us. Our then-Department chair, who was sitting next to me, looked at me with a shocked expression. He thought that I’d just called Dave a “Eunuch Wizard.”
Vocabulary is important, no?
The following cartoon from xkcd will, with careful inspection, provide a gestalt of thethe geek-jock mentality (who find this funny but also wish it were true):
So what do you need to know to speak with geeks?
Here is a quick self-evaluation. If you can explain what all these TLAs (three-letter acronyms) mean, then you can probable speak to geeks. If not – read the tutorial, wherein you will learn all these, and more.
What do you need to know about hardware to deal with IT issues in your ED?
Every couple of years, I’ve had to revamp the presentation entirely, because the technology has changed so much – for instance, who needs to know about types of floppy disk drives, or the difference between DVD and CD drives? All you need to to is make sure a PC has a CD drive and it will read whatever you need.
Details of CPUs have gone out the window, because even the cheaper CPUs will do just about anything you need to do in the ED or office or ward. (Even 3D visualization of CT scans is trivial to today’s CPUs.)
But there are still some techie things that you may need to talk with the IT folks about, such as video resolution and quality. High-resolution displays are still relatively expensive, and not yet a commodity product like CPUs or CD drives. And high-resolution displays are needed to view X-rays and CT scans well. While you don’t need to know details about brands of LCD displays, you should know enough about color depth and resolution that this table makes sense to you:
You also need to know enough about networking that you understand the basic definition of LAN, WAN, VPN, Internet, Intranet, RJ-45/Cat5, twisted-pair, and coax. You certainly don’t need to be able to debug networks, just to understand the basic, common terminology.
You need to know what ASCII is, what hex, decimal and binary are. You need to know about both software firewalls (e.g., Norton Internet Security, ZoneAlarm and hardware firewalls, (e.g., a router) for your own safety, as well as to be able to discuss enterprise firewalls with your IT staff. You need to know what makes an enterprise database (scalability, relational) and the common enterprise databases: SQL “sequel server”, Oracle, Sybase, and the free mySQL. You need to know at least a bit about Operating Systems that run on PCs. The diagram will help a bit, but this series of sayings from alt.folklore.computers captures what you need to know:
DOS AIR: All the passengers go out onto the runway, grab hold of the plane, push it until it gets in the air, hop on, jump off when it hits the ground again. Then they grab the plane again, push it back into the air, hop on, et cetera.
MAC AIRWAYS: The cashiers, flight attendants, and pilots all look the same, feel the same, and act the same. When asked questions about the flight, they reply that you don’t want to know, don’t need to know and would you please return to your seat and watch the movie.
WINDOWS AIRLINES: The terminal is very neat and clean, the attendants all very attractive, the pilots very capable. The fleet is immense. Your jet takes off without a hitch, pushing above the clouds, and at 20,000 feet it crashes without warning.
UNIX EXPRESS: Each passenger brings a piece of the airplane and a box of tools to the airport. They gather on the tarmac, arguing constantly about what kind of plane they want to build and how to put it together. Eventually, they build several different aircraft, but give them all the same name. Some passengers actually reach their destinations. All passengers believe they got there.
WINDOWS VISTA AIRLINES: You enter a good looking terminal with the largest planes you have ever seen. Every 10 feet a security officer appears and asks you if you are “sure” you want to continue walking to your plane and if you would like to cancel. Not sure what cancel would do, you continue walking and ask the agent at the desk why the planes are so big. After the security officer making sure you want to ask the question and you want to hear the answer, the agent replies that they are bigger because it makes customers feel better, but the planes are designed to fly twice as slow. Adding the size helped achieve the slow fly goal.
Once on the plane, every passenger has to be asked individually by the flight attendants if they are sure they want to take this flight. Then it is company policy that the captain asks the passengers collectively the same thing. After answering yes to so many questions, you are punched in the face by some stranger who when he asked “Are you sure you want me to punch you in the face? Cancel or Allow?” you instinctively say “Allow”.
After takeoff, the pilots realize that the landing gear driver wasn’t updated to work with the new plane. Therefore it is always stuck in the down position. This forces the plane to fly even slower, but the pilots are used to it and continue to fly the planes, hoping that soon the landing gear manufacturer will give out a landing gear driver update.
You arrive at your destination wishing you had used your reward miles with XP airlines rather than trying out this new carrier. A close friend, after hearing your story, mentions that Linux Air is a much better alternative and helps you buy your return ticket home.
As far as learning CIOspeak, you need to understand the current state of standardization of computer-based clinical charts. If you find this confusing, then you have a good understanding as the field itself is quite confused.
There is more in another sidebar page, and a summary diagram, but in overview: people realized we needed standards for how to format and exchange these computer-based clinical charts. ASTM started working on standards (CCR), and so did HL7 (CDA, CCD). They came up with different incompatible standards, but the standards covered different stuff, so they only overlapped (and were incompatible) a bit. So, they worked on making them compatible.
The US national government insisted on standards as well, so this helped ASTM and HL7 get together on standards. As of 2008 there were at least standard definitions and a basic understanding of EMR, EHR, and PHR (with which Google and Microsoft are eager to help you). While these definitions are only “official” in the USA, they will likely have a big impact worldwide.
In order to speak intelligently with the CIO, you need to be able to understand, at least at a basic level, what’s going on here, and be able to at least recognize the important acronymic organizations involved. And you need to practice, so you can say “HITSP” (HIT-spee) without spitting on your CIO.
A high-level overview-type appreciation of XML is important, as most data exchange these days is via XML.
Finally, one needs to appreciate the Herculean tasks faced by a hospital CIO. The above cartoon about the “butterfly effect” (known more scientifically as “sensitive dependence on initial conditions”) points up that, if a CIO changes one part of a hospital’s massively-interconnected computer systems, it will have effects (often unexpected and unpleasant effects) in other systems. Thus, an understandable desire on the CIO’s part to not change things unless they really, really need changing.
Several years ago, the main hospital where I’ve worked for 20+ years (a Level I Trauma/Burn Center, Stroke Center, tertiary care teaching hospital), was absorbed into one of the largest health systems in the country. That meant a change in computer systems. At an early meeting with the new hospital CIO, he gave out the diagram here, listing the major new hospital computer systems and how they interact. I scribbled a few notes on it in pencil. I don’t expect you to be able to really read it (certainly not my scribbled notes). But it does provide a feel for the complexity of hospital computer systems as a whole.
The Healthcare IT in a Nutshell page has more on all of these topics, with links for further reading.
As far as ED-specific IT, you need to be able to clearly enunciate to others the needs of the ED’s work processes. While these needs are similar in some ways to both inpatient and outpatient settings, but in some ways, the ED is unique, and these unique needs have resulted in certain specific computer programs/functions. If you look at the “blob” diagram – which Dr. Alan Forstater and I first sketched on a napkin circa 1995 as we discussed the first of what is now the annual International Symposium on ED Information Systems – you’ll see that the two major functions in the ED are charting (which has much in common with inpatient and outpatient physician and nurse charting) but also ED tracking. ED tracking systems are, in some wise, unique to the ED setting.
The best way to learn ED-specific IT is to attend the annual ED Information Systems Symposium, or at least to spend some time browsing the content on the conference website. Most of the content on this site also relates to ED-specific IT in at least some way.
As you can tell from the “blob” diagram, charting and tracking are the big chunks of ED IT with which you’ll be dealing with. I plan to post here about both charting and tracking – watch this space!
And now, it’s time for you to go to the Healthcare IT in a Nutshell page and buckle down to work.