Join Section

Emergency Medical Informatics Section Newsletter - December 2008 - Vol 14, #1


circle_arrow From the Chair
circle_arrow From the Editor
circle_arrow Comments on the Joint Commission’s Sentinel Event Alert for HIT
circle_arrow Preliminary Results from ACEP Technology Survey 2008
circle_arrow HITSP Releases First Emergency Response EHR
circle_arrow Informatics Acronym Salad: A-C
circle_arrow ACEP Section Grant Opportunities
circle_arrow SACEP/ASPR Emergency Care Policy Fellowship

Newsletter Index



From the Chair

Dr. Vernon D. Smith, MD

Vernon D. Smith, MDThe Section and its members have been quite active over the last several months!  Our membership stands at about 325 members, we have produced a Newsletter; lent faculty support to the Pennsylvania Emergency Department Information Systems Symposium held in December 2008 in San Diego, and several section leaders are nearing completion of an ACEP information systems white paper pursuant to Resolution 22 (2007).  The Section also received a grant to incorporate ACEP clinical policies in decision support systems.  The Principle Investigator is Dr. Ted Melnick, with Co-Investigators Drs. Finnell and Nielson.  The team will be looking at appropriateness and what would the workflow be and at what point they would be inserted (alerts).  The Section was also awarded the ACEP Service to College Award, recognizing the Section’s exceptional work in meeting the College’s strategic objectives from October 2006 through October 2007, and is a testament to how strong and active the Section and its members are.

Following our Annual Meeting, in Chicago, our Officers for 2008-2009 are:


Chair Vernon D. Smith, MD 
Chair-elect James C. McClay, MD, FACEP
Immediate Past Chair Craig F. Feied, MD, FACEP
Secretary/Newsletter Editor Jeffrey A. Nielson, MD, MS
Councillor Randall B. Case, MD, MBA, MSE, FACEP
Alternate Councillor R. Carter Clements, MD
Board Liaison Michael J. Gerardi, MD, FACEP
Staff Liaison

Angela Franklin, Esq.

Welcome to the Section and we look forward to another active and successful year!





Back to Top

From the Editor

Jeff Nielsen, MD MS

We are calling for Newsletter submissions! We’d like to add to the variety of our content.  If you’re working on something interesting, please tell us about it.



Back to Top

Comments on the Joint Commission’s Sentinel Event Alert for HIT

Jeff Nielson, MD MS

Jeff Nielson, MD, MSOn December 11, 2008, The Joint Commission (JC, formerly JCAHO) issued a Sentinel Event Alert on safe implementation of Health Information Technology (HIT) and converging health technologies.  It is published electronically at their website:
. Sentinel Event Alerts are released when JC recognizes "an unexpected occurrence involving death or serious physical or psychological injury, or the risk thereof." The JC releases a summary to describe common underlying causes with suggestions to prevent future occurrences.  Interestingly, almost everything in the essay is related to human factors, probably the greatest cause of IT failures and frustrations.

"The overall safety and effectiveness of technology in health care ultimately depend on its human users, ideally working in close concert with properly designed and installed electronic systems. Any form of technology may adversely affect the quality and safety of care if it is designed or implemented improperly or is misinterpreted. Not only must the technology or device be designed to be safe, it must also be operated safely within a safe workflow process."

This supports what many of have been saying for years and I’m excited to hear JC saying it.  Another interesting thing is that the alert discusses a convergence of medical devices and HIT.   To nitpick: we have seen this a long time coming, but until you just pull a computer out of the box, turn it on, and start documenting like we do with H&P sheets, this doesn’t really hold. I do really look forward to that day.  However, there is an underlying message—that perhaps the way we approach regulation of the information systems might someday approximate that of medical devices.  A scary day for the vendors indeed.

The end of the essay has a list of 13 suggested actions.  It really is an excellent list and looks like it came right out of an IT operations text.  A couple caught my eye as worthy of mention.

  1. Examine workflow processes and procedures for risks and inefficiencies and resolve these issues prior to any technology implementation. Involving representatives of all disciplines—whether they be clinical, clerical or technical—will help in the examination and resolution of these issues.

I often hear of people leaving registration out of the discussion and regretting it.  Others select a system without any discussion with IT first.

  1. To improve safety, provide an environment that protects staff involved in data entry from undue distractions when using the technology.

I’m not sure how to apply that to the ED.

  1. After implementation, continually monitor and report errors and near misses or close calls caused by technology through manual or automated surveillance techniques. Pursue system errors and multiple causations through the root cause analysis process or other forms of failure-mode analysis. Consider reporting significant issues to well recognized external reporting

This is something I’m going to start now.  My ED doesn’t keep internal listings of near misses.  We have relied on IT reporting, which is subject to their bias and conflicts of interest.

This is indeed one of the best reads from the Joint Commission that I’ve seen lately.  I recommend you read it entirely and comment on the email list.




Back to Top

Preliminary Results from ACEP Technology Survey 2008

Jeff Nielson, MD MS

In early 2008, IBM became an ACEP sponsor.  IBM and ACEP both wanted to know more about the status of technology in the practice of emergency physicians, and what role the physicians have in technology decision making.  A survey was formulated and emailed to all ACEP members.  Here I present a subset of the data.

Physicians were asked "What are your top three business or technology issues/challenges impacting the emergency department?"  511 of 563 respondents answered this question. Each respondent’s list was collected as a single text response.  The responses were categorized, without a ranking.  Categories were formulated in response to the answers.  Full categorization was deferred due to time constraints and only the first 50 respondents answers are shown here.  60% felt that "data standards and sharing between systems" was one of the top 3 issues.  "Speed and ease of use" also stands out as a key issue, not surprising to those of us that work those busy Monday evenings.


Respondents were asked "In your practice, are computers or other forms of information technology used?" 99.1% responded positively.  Of these, the following was requested: "indicate all uses that apply for information technology."  A list of items was provided of which they could chose as many as needed.  Diagram 2 shows the responses.


A third question was related to how they would like to learn more about technology.  Diagram 3 shows that responses per pretty evenly divided.   Looking over existing EP technology offerings, I would estimate that in-person seminars are over-represented and the others are underrepresented.


Although this study’s population sampling methods are suboptimal, this survey provides some evidence of the current status of technology in EDs, as well as the learning preferences of emergency physicians. 



Back to Top

HITSP Releases First Emergency Response EHR

Jeff Nielson, MD MS

On August 20, 2008, the Healthcare Information Technology Standards Panel (HITSP) released the implementation version of the Interoperability Specification for the Emergency Response – Electronic Health Record (ER-EHR).   This constitutes the first government-facilitated standardization of disaster-related communication of data.  It truly represents a step forward in the organization of disaster response.  It has been submitted to the National Health Information Network (NHIN) sites for trial implementation.  These sites have grants to implement the system.

The ER-EHR is not a standard in itself.  Technically, it is a specification that defines which types of standards should be used in which circumstances.  It specifies each of the data customers involved in a disaster, it specifies what type of messages they might need, and it specifies the format in which it should be communicated.  Each of these formats has to be chosen from standards that are actively maintained and approved by a standards development organization, among other requirements.

Ultimately, the ER-EHR’s focus shifted to non-clinical data.  It provides a mechanism by which clinical data might be communicated all the way from the non-clinical first responder to the follow-up provider.  However, this subset of the data is the least well-specified.  Due to a variety of factors, the volunteer committee had little long-term physician input, and much of the work had to be devoted to simply understanding the complexity of disaster response.  Thus the final product is a function of the unique needs of disasters.

ACEP did have input into the process.  Two informatics section members, Ed Barthell, MD and Jeff Nielson, MD, provided significant input into the domain analysis and education of the committee on ED-related and clinical information processes.  Since the scope for the project was so large, ACEP’s greatest contribution came in helping HITSP understand existing data flow processes and how their recommendations had to provide for the transitions from the existing state to where HITSP and ACEP wanted to arrive.  One of our most important comments was that the data processes be activated both with and without disaster activations, so that work processes don’t need to significantly change when the system is most stressed. 

There had been some pushback from NHIN sites since the specifications are quite loose in most areas.  For example, some documents are simply specified as being sent as PDF files, which doesn’t specify content or allow for machine interpretation or summary.  This does allow for human readability and is perhaps an important first step in facilitating information flow.

The ER-EHR is again being reviewed (v1.2.2) and expected to be in constant revision so as to allow for NHIN sites and others to provide feedback.  Participating ACEP members hope that this process allows for eventual improvement in clinical communication for disaster summary and better patient outcomes.

To download the document, visit HITSP’s web site:




Back to Top

Informatics Acronym Salad: A-C

By Keith Conover, MD FACEP

With so many terms to learn in Healthcare IT, we thought sharing some terms in each newsletter would be helpful.  Many have links so you can learn more.

  • ADSL: Asymmetric Digital Subscriber Line (commonest form of broadband over phone lines)
  • AFAIK: As Far As I Know (email)
  • AGP: Accelerated/Advanced Graphics Port
  • AHIC: American Health Information Community Major healthcare IT organization.
  • AJAX: Asynchronous JavaScript and XML (e.g., the technology behind Google Maps)
  • AMD: (1) Active Matrix Display; (2) Advanced Micro Devices, Inc.
  • ANSI: American National Standards Institute
  • Architecture: the structure of an information system and how its pieces communicate and work together. Also see client/server.
  • .ASC: ASCII text
  • ASCII: American Standard Code for Information Interchange The standard for simple text files. Pronouned "ass’-key."
  • .ASM: Assembler Source Language
  • .ASP: Active Server Page (file name extension)
  • ASP: (1) Association of Shareware Professionals (2) An Application Service Provider deploys, hosts, and manages access to software applications for multiple parties from a central facility. The ASP charges a subscription fee to users of the applications, which are delivered over the Internet or other public or private networks.
  • ATA: Advanced Technology Attachment (original hard drive interface)
  • ATM: (1) Adobe Typeface Manager; (2)Asynchronous Transfer Mode
  • Autoexec: Automatic Execution file (AUTOEXEC.BAT automatically executed on startup of DOS systems)
  • B2B: Business to Business
  • .BAK: Backup
  • Bandwidth: bandwidth is how much information can be transmitted at once through a communication medium, such as a telephone line, fiber-optic cable, or radio frequency.
  • .BAS: Basic Language (N.B. Niklaus Wirth insisted that anyone who learned to program in BASIC was irretrievably brain-damaged.)
  • .BAT: Batch file
  • Beaming: Transfer of data or software programs between devices, such as PDAs, personal computers and printers, using either infrared or radio-wave transmission.
  • Biometric Authentication: Technology that identifies a person through recognition of unique physical characteristics, such as retina or iris patterns, face shape, voice patterns or fingerprints.
  • .BIN: Binary
  • BIOS: Basic Input/Output System (system chips)
  • Bit: The undivisible elementary particle of classical digital data. A bit is either on (1) or off (0). If someone starts talking about how this is not really true for quantum computing just ignore them. As Bacon observed: we are more likely to reach the truth through error than through confusion.
  • Bluetooth: A protocol designed for short-range wireless communication or networking among a variety of devices. Somewhat similar to, but distinct from, 802.11x (WiFi).
  • .BMP: Bitmap Picture
  • BPS: (1) Bits Per Second; (2) Bytes Per Second
  • Broadband: A medium that can carry multiple signals, or channels of information, at the same time without interference. Broadband Internet connections enable high-resolution videoconferencing and other applications that require rapid, synchronous exchange of data. WiFi, cable modem, satellite, WiFi and EVDO/3G cellular laptop modems are examples.
  • Browser: A software program that renders (shows) documents written in HTML, the primary programming language of the World Wide Web. Common browsers include Firefox, Safari, Opera, Chrome and Microsoft Internet Explorer, all of which render HTML with slight differences.
  • BsoD: Blue (or black) Screen of Death: Windows just died (again)
  • Byte: eight bits.
  • CCHIT: Certification Commission for Healthcare Information Technology.  Major healthcare IT organization.
  • C/C++/C#: C is an established programming language found in many operating systems, including UNIX. C++ and C# are popular descendants of C that incorporate object-oriented features. Also see Java.
  • CAD: Computer Aided Design
  • CAPTCHA: A Completely Automatic Public Turing Test To Tell Computers and Humans Apart Requiring users to read and input semi-illegible text is a common method.
  • CAT5: computer network cable
  • CC: Carbon Copy (email)
  • CD-R: Compact Disk - Recordable
  • CD-R/W: Compact Disk - Rewritable
  • CD-ROM: Compact Disk - Read Only Memory
  • CDMA: Code-Division Multiple Access (wireless/cellphone protocol)
  • CDPD: Cellular Digital Packet Data (wireless protocol)
  • CERT: Computer Emergency Response Team.CFG: Configuration
  • .CGM: Computer Graphics Metafile
  • Charting Software: "Charting" is the common term for physician and nurse clinical documentation. Charting software can be "structured" or unstructured.

    Structured charting requires physicians and nurses to choose items from predefined lists, usually in a very deeply-nested hierarchical menu. This may be done by mouse or touchscreen ("point and click") or by typing the first part of each menu selection and pressing Enter ("type and click"). For example, one would click on menu options such as: Physical Exam > HEENT > Throat > Injected, then click on Physical Exam > neck > lymph nodes > anterior adenopathy… Structured charting provides structured data which can be quite valuable for research and administration.

    For relatively simple repetitive charting, structured charting can be reasonably efficient. This is likely why most ED nurses (unlike most ED docs) find structured charting acceptable.
    However, for more complex and less repetitive tasks, such as emergency physician charting, structured charting is much less efficient. Structured physician charting is extremely expensive, given the hourly cost of physician time ("physicians are expensive data-entry clerks").

    Structured charting provides reminders to include items, such as pertinent negatives or things that are routinely done but sometimes forgotten when charting. For example: that the fontanel is normal in pediatric examinations; or, that thrombolytics were considered but not thought appropriate for a patient with a stroke. This is important for risk management/legal reasons, and for billing.

    Unstructured charting, such as dictating into a telephone, can be parsed to create structured data, even in realtime (for example, analyzing a physician’s ED note for compliance with the required number of Review of Systems and Physical Exam items for billing) but this has not been widely used. The traditional model is to send such dictations for typing by trancriptionists. Speech-recognition software is used on the dictation and only then the transcriptionist corrects speech-recognition errors. As speech-recognition continues to improve, self-edit mode is becoming more common: the dictation appears on the physician’s computer screen and is edited as it is dictated. This takes some physician time, but charts are complete and signed soon after the patient encounter.

    A hybrid approach uses speech-recognition for structured-charting free-text areas instead of typing. (The History of Present Illness and Medical Decision-Making sections are particularly suited for this.) Many niche EDIS vendors offer this.

    Another hybrid approach is to use speech as the primary input mode, but allowing physicians to navigate structured templates by voice, which is by accounts faster than the above hybrid method, but does not produce structured data. Nuance (previously Dictaphone) offers Powerscribe emergency medicine – though it has not been significantly improved in several years – and Enterprise Workstation, which is their flagship product for self-editing.
  • .CHK: CHKDSK is a DOS/Windows utility that CHecKs the hard DiSK and attempts to save data after a software or hardware "crash"; it may produce .CHK files with at least some of the lost data.
  • CIO: Chief Information Officer
  • CGI-BIN: Common Gateway Interface – Binary (programming for Web forms)
  • Client: In a computer network, a workstation that retrieves information from a server.
    Client/server: A network system in which a dedicated computer (server) handles some data storage and processing tasks for applications used on personal computers or workstations (clients, which are usually a PC), which tap the server’s shared files and processing power as needed. Thin clients are basically "dumb terminals" and leave all the work to the server. Thick clients do a fair bit of work on the workstation.
  • CMOS: (1) Complementary Metal-Oxide Semiconductor (type of nonvolatile memory chip); (2) PC configuration stored on CMOS
  • CMYK: Cyan-Magenta-Yellow-Black (color model)
  • COAX: Coaxial Cable (for Ethernet and similar networks)
  • .COM: Error! Hyperlink reference not valid.
  • COM1: First serial Port (asynchronous port)
  • COM2: Second serial Port
  • CPOE: Computerized Provider Order Entry is a process of electronic entry of instructions for the treatment of patients (particularly hospitalized patients). These orders are communicated over a computer network to the medical staff (nurses, therapists, pharmacists, or other physicians) or to the departments (pharmacy, laboratory or radiology) responsible for fulfilling the order. The CPOE system may compare the order against standards for dosing, may check for allergies or interactions with other medications, and may warn the practitioner about potential problems. CPOE systems designed with good user interaction may decrease delay in order completion, reduce errors related to handwriting or transcription, allow order entry at point-of-care or off-site, provide error-checking for duplicate or incorrect doses or tests, and simplify inventory and posting of charges. However, many CPOE systems with poorly-designed user interfaces have introduced major new sources of error and have been deinstalled or replaced with somewhat-better versions. See usability guru Jakob Nielsen’s article Medical Usability: How to Kill Patients Through Bad Design.
  • CPU: Central Processing Unit
  • CRT: Cathode Ray Tube: standard type computer monitor display
  • CSID: Call Subscriber ID (for FAX and phone caller ID)
  • CSLIP: Compressed Serial Line Interface Protocol [Internet]
  • CSV: Comma-Separated Value/Variable (file type)
  • CTRL: Control (computer keyboard key)

Stay tuned for more terms in the next newsletter!




Back to Top

ACEP Section Grant Opportunities


The application process for the 2008-09 Section Grant program began November 7th. Section Grants are designed to meet sections’ needs in educating the public and furthering the advancement of emergency medicine.

  • Projects funded by Section Grants must demonstrate a time commitment from members of the section.
  • The project coordinator must be a section member.
  • The Section Grant letter of intent and full proposal must be reviewed, approved, and signed by the section chair

Complete information about applying for Section Grants can be found at:; the ACEP Section Grant Schedule is below.

Schedule for 2008-09 Application Process

November 7, 2008 Section Grant Program schedule e-mailed to all section staff liaisons with instructions to forward to all section members via e-lists
January 4, 2009 E-mail sent to section officers reminding them of Letter of Intent deadline
February 16, 2009 Postmark, e-mail, or fax deadline for Letters of Intent

February 18 - 
March 6, 2009

Staff review and comment on Letters of Intent
March 10, 2009 Letters of Intent along with staff comments sent to Section Grant Task Force via e-mail for review
March 31, 2009 Task Force conference call at 10:00 am Central time to determine from which sections to request full proposals
April 3, 2009 Section Chair and Project Coordinator notified of results of the Letter of Intent review. Full proposals requested. Section Grant Task Force Chair provides feedback to sections with unsuccessful Letters of Intent
May 4, 2009 Postmark, e-mail, or fax deadline for Final Applications
May 8, 2009 Final Applications sent to Task Force via e-mail for review
May 29, 2009 Task Force Conference Call at 10:00 am Central time to decide on recommendations to the Board of Directors
June 2, 2009 Recommendation for funding due for June Board meeting
June 23 - 24, 2009 June Board Meeting
June 24, 2009 Sections notified of awards



Back to Top

ACEP/ASPR Emergency Care Policy Fellowship

Department of Health and Human Services
Office of the Assistant Secretary for Preparedness and Response (ASPR)
American College of Emergency Physicians (ACEP)

ACEP/ASPR Emergency Care Policy Fellowship        

One-Year Appointment

  • One year appointment available as Emergency Care Policy Fellow at HHS Office of the Assistant Secretary for Preparedness and Response (ASPR).
  • Opportunity to engage in collaborative emergency care and disaster preparedness policy development with medical professionals in the HHS Emergency Care Coordination Center (ECCC).
  • Review and analyze developments involving emergency medical care, identifying areas that require attention and stimulating new research and policy initiatives to address these areas.
  • Full-time position over one year period to begin early 2009 (date negotiable).
  • Position located within U.S. Department of Health and Human Services in Washington, DC.
  • ACEP provides $60,000 stipend.
  • Fellow's sponsoring institution supports other expenses.
  • Opportunity to work clinically in DC area emergency department.


  •  Mid-level faculty in Emergency Medicine (minimum 5 years post residency)
  • Completion of ACGME emergency medicine residency and recommended ABEM/ABOEM board certification
  • Full-time appointment at academic institution
  • Support letter from Fellow’s sponsoring institution


  • Participate in the continued implementation of aspects of Homeland Security Presidential Directive (HSPD) #21.
  • Participate and present at the National Disaster Medical System (NDMS) Conference.
  • Collaborative development and networking in EMS and disaster medicine with national leaders from government and the private sector.

Application Deadline: January 5, 2009

Please send your CV, letters of support, and a letter of intent expressing your interest in the fellowship position. These should be sent to Rick Murray, EMS and Disaster Preparedness Dept., American College of Emergency Physicians, P.O. Box 619911, Dallas, Texas, 75261 or via e-mail at For more information, contact Rick Murray at 972-550-0911. ext. 3260 or



Back to Top

This publication is designed to promote communication among emergency physicians of a basic informational nature only. While ACEP provides the support necessary for these newsletters to be produced, the content is provided by volunteers and is in no way an official ACEP communication. ACEP makes no representations as to the content of this newsletter and does not necessarily endorse the specific content or positions contained therein. ACEP does not purport to provide medical, legal, business, or any other professional guidance in this publication. If expert assistance is needed, the services of a competent professional should be sought. ACEP expressly disclaims all liability in respect to the content, positions, or actions taken or not taken based on any or all the contents of this newsletter.

Click here to
send us feedback