Join Section

Emergency Medical Informatics Section Newsletter - September 2006, Vol 11, #2

sectionHead_informatics.jpg

circle_arrow From the Chair
circle_arrow Welcome New Informatics Section Members!
circle_arrow Frenetic Pace of Federal HIT Activities Continues
circle_arrow An Introduction to Web Services
circle_arrow Human-Computer Interfaces in the ED: Part Three of an Ongoing Series

Newsletter Index


button_informatics_section

 

From the Chair

Craig F. Feied, MD, FACEP

Dear Colleagues:

I'd like to give a little background and perspective on some recent events that have been covered in the media.

During the past quarter-century, I've worked intensively with a core group of emergency informaticists to develop practical clinical informatics solutions that can actually make a palpable difference for the practicing clinician. Mark Smith, MD, FACEP, and I began a focused informatics effort together in 1983, and over the past decade, Jon Handler, MD, FACEP, and Mike Gillam, MD, have joined us as full-time participants in that effort. In 1993 we founded the non-profit National Center for Emergency Medicine Informatics (NCEMI), and a few years later we also established the National Institute for Medical Informatics and the Advanced Projects Group at the Medical MediaLab. Ed Barthell, MD, FACEP, and Meera Kanhouwa, MD, have been close collaborators on many projects of mutual interest, and we've also worked with Todd Rothenhaus, MD, FACEP; Vernon Smith, MD; Tony Shannon, MD; Kevin Coonan, MD, and many other members of the ACEP Informatics Section. Outside of emergency medicine, we've had many other collaborators from across the country and around the world.

We've pursued diverse informatics research projects involving such wide-ranging areas as data-centric computing, robotics, facial image capture, gesture recognition, climate and health, biosurveillance, situational awareness, federated authentication, ghostly teleconferencing, vocal interfaces, brainwave sensing, holographic imaging, and other cool and unusual concepts. We've received millions of dollars of grant funds to support such novel projects, but since 1995 our primary focus has been on the internally-funded development of an innovative large-scale enterprise information system that we call "Azyxxi."

Today Azyxxi receives data from nearly every possible source across the enterprise, and provides ubiquitous sub-second access to all clinical and non-clinical data for any patient or other entity. With more than 12,000 data elements available for a typically complex patient, clinicians are only a click away from any x-ray, angiogram, CT scan, 3D anatomical image rendering, lab result, dictation, scanned chart page, ventilator setting, or anything else of interest. In less than a second, we can look at all patients in a particular location, or all patients with a particular doctor, or everybody with chest pain, or all females younger than 59 who arrived after 4 pm on a Tuesday. Azyxxi includes a lot of tools for analysis and reporting, along with user-configurable alerts and alarms, decision-support components, and a whole lot more. As clinicians, the system is exactly what we dreamed it would be: a way to get exactly what we want, instantly and intuitively, with essentially zero effort.

Many of you will already have heard the news that Microsoft recently agreed to acquire the Azyxxi clinical information system and make it commercially available. That transaction is now nearly complete. By the time this appears in print, Jon Handler, Mike Gillam, and I will almost certainly have become employees of Microsoft, along with our entire development team. Interestingly enough, there will now be four former ACEP Informatics Section leaders on the Microsoft Health team: Meera Kanhouwa, another former section president, already joined another Microsoft division a year or two earlier, and she's now transferring to the Health Solutions Group to join the Azyxxi team.

The news media has already covered the story of "Microsoft Buys Azyxxi" in a standard press release fashion, but I would like to offer a behind-the-scenes perspective on the acquisition and the reasons for our decision to join Microsoft. Our entire professional lives have been lived in the academic, not-for-profit world, and have not previously been tied to any commercial interest. Entering the commercial arena was not a decision we took lightly, but we've become convinced that Microsoft is the right platform from which to pursue our long-standing goal - to improve clinical care across the entire country by helping to make all available information instantly and ubiquitously available.

Historically, Azyxxi began as a targeted solution to help us transform a beleaguered emergency department. After a rapid initial success in that arena, Azyxxi was quickly pulled throughout the hospital and then into other hospitals across the enterprise. As it has grown, it has transformed our entire approach to clinical practice and to operational management, sometimes in surprising and unforeseen ways.

Over the years, Azyxxi has had its share of media attention and has survived scrutiny by many outside groups. Azyxxi was adopted by the US Department of Health and Human Services for deployment in the HHS Secretary's command center. It was deployed by the states of Maryland and Virginia for use in Katrina refugee tracking. It completed a successful pilot at the Cleveland Clinic. It has been the basis of Regional Health Information Organization (RHIO) planning in several states and multi-state areas. Harvard Business School has written a series of five case studies about what we've accomplished. We've been looked at by some large health care I/T vendors, and also by companies like IBM, ATT, Lockheed-Martin, and others.

However, the scale of the scrutiny we've undergone as part of this Microsoft acquisition has been something entirely different. The due diligence phase has taken more than 8 months of intensive effort. Our entire code base (more than 10 million lines of code) was scrutinized by a series of third-party experts who assess security issues, code quality, documentation, operational practices, intellectual property issues, and a million other possible stumbling blocks. We're very happy that Azyxxi survived that scrutiny and came through with flying colors. The final outcome is that Microsoft is acquiring Azyxxi and will make it immediately available to selected partners in the health care marketplace.

Azyxxi will be positioned initially as an enterprise-scale "Health Intelligence Engine." The idea is for Azyxxi to be used in conjunction with other installed systems, rather than as a replacement for anything in particular. Azyxxi will provide a unified view of all the data that is created in many different systems across the enterprise, and will deliver built-in tools to help with error reduction, task automation, analysis, reporting, research, strategic planning, and – oh, yes – clinical care.

Why Microsoft?

In real terms this isn't a very large deal (securities analysts rated it "non-material"), but Microsoft seems to be seriously committed to putting powerful tools right into the hands of clinicians, even if that disrupts the established balance of power a little bit. We really like that idea. In the past, we had entertained larger offers from other vendors, but until now, the answer from our team had always been "no." We were dealing with well-known companies who were commercially successful, but it was clear to us that they didn't quite "get it," and we didn't want to lose something that seems to us pretty special. In contrast, it's very clear to us that Microsoft "gets it." Like us, Microsoft believes in the power of informatics to improve the practice of medicine in a fundamental and important way. Our mutual goal is to improve medical care by modifying the environment in which care is delivered, in such a way as to make those changes global and enduring.

The Microsoft Health Solutions group is headed by Peter Neupert, who formerly led the OS2 development project and the MSNBC project. Many people also know him as the highly-successful founder of Drugstore.com. Peter is a smart and charismatic person who came out of retirement in order to make a difference in health and wellness, and who chose Azyxxi as one of the cornerstones of that effort. As talks progressed, we learned some things that helped us to believe Microsoft would provide a very good home for Azyxxi.

Health care informatics is a tough industry, so it was important to us to know that Microsoft can't be chased out of the market by any of the usual tactics. Microsoft is the largest software company in the world, with a strong balance sheet and plenty of cash on hand. It already sells more than a billion dollars of software in the health care industry each year. If necessary, it can afford to take short-term losses to build up a business position, and it can afford to invest seriously for the long-term. It can afford to invest in good ideas that others can't afford to try. It doesn't have an established legacy system to protect, so it isn't afraid of disruptive change in health care. Most importantly, Microsoft is not afraid to deal directly with the doctor or directly with the patient – its business has historically been built by delivering power into the hands of end-users, even when that worked against corporate centralization of control.

For us, one attractive aspect of Microsoft comes from the mere existence of the Bill and Melinda Gates Foundation. With an endowment of more than $60 billion and yearly targeted expenditures of $5 billion, the foundation has made health and education its global priorities. Although we know there's no connection between the Gates foundation and Microsoft, it's pretty clear that Microsoft's chairman has a strong commitment to the same kinds of issues that matter to us, and that can't hurt. It has become clear that in the hands of Microsoft, Azyxxi will not just be a shiny informatics technology available only in resource-rich academic centers. Microsoft has special divisions working to deliver affordable and sustainable solutions in the developing world, and these groups are already exploring ways to deliver Azyxxi in countries where there's currently no business case for that to happen.

On the practical side of things, we're keeping our existing development environment at MedStar health, so our day-to-day working situation really isn't going to change much. We'll still be based at WHC in Washington, DC, with the same team working on the same projects. I'll be leading Azyxxi development on the Microsoft side, while Mark Smith will remain at MedStar as chairman of emergency medicine and primary liaison between MedStar and Microsoft. Although we've been very successful at MedStar, most members of this section will understand exactly how I feel about gaining some distance from a CIO who doesn't think hospitals should be in the software development business, and finding a new home in an organization that really values software development.

All of us from NCEMI are really looking forward to what we can accomplish from this new platform, given a little time and some resources. Many section members have been encouraging and supportive of our work over the years, for which we are truly grateful. We think this next step could be pretty cool, and we look forward to our continuing collaborative work with all of you in the field of clinical informatics.

Back to Top


Welcome New Informatics Section Members!

Kevin Allen - Harris Methodist HEB Hospital - Bedford, TX
Majed Althagafi - Ottawa, Ontario, CANADA
Harriet Burris - River Hospital - Alexandria Bay, NY
Steven Baldwin - Children's Hospital - Birmingham, AL
Kevin Coonan - University of Utah School of Medicine - Salt Lake City, UT
Peter Cridge - University Medical Center at Princeton - Princeton, NJ
Aaron Hettinger - University of Rochester School of Medicine - Rochester, NY
Lester Kallus - State University of New York - Stony Brook, NY
David Kaminski - North Carolina
Glen Kay - St. Luke's Hospital - Newburgh, NY
Martin Kohn - Winthrop University Hospital - Mineola, NY
Michael Liao - Barnes Jewish Hospital - St. Louis, MO
Sanjay Mehta - Hospital for Sick Children - Toronto, Ontario, CANADA
Lawrence Miller - Memorial Medical Center - Springfield, IL
Michael Molloy - Cork University Hospital - Cork, Ireland
Kevin Stacks - Texas
John Strayer - Washington
Garrett Taylor - Avera McKennan University Hospital - Sioux Falls, SD
Richard Winters - St. Agnes Medical Center - Fresno, CA

Back to Top


Frenetic Pace of Federal HIT Activities Continues

Ed N. Barthell, MD, FACEP

Since the pronouncement by President Bush that a goal for the country should be universal electronic medical records in the next 10 years, and the subsequent establishment of the Office of the National Coordinator (http://www.hhs.gov/healthit/), multiple parallel activities have been rapidly proceeding. Many of these activities are directly addressing the issues of information exchange in emergency medicine.

Health and Human Services Secretary Mike Leavitt serves as chair of the American Health Information Community (AHIC), which can be viewed as a sort of national board of directors for HIT. The AHIC has in turn designated several areas of emphasis in order to encourage "breakthroughs" in the use of information technology to improve the health care system. The intent is for significant advances to occur in each of these breakthrough areas over the next 1-3 years.

The first three breakthrough areas are use of electronic health records (EHR), the creation of effective patient-controlled records (PHR), and biosurveillance (Bio). AHIC workgroups have been created to address each of these breakthrough areas. Chronic care has been suggested as a potential fourth breakthrough area, and emergency response is potentially another new breakthrough area that will be detailed further below.

Each of the first three breakthrough areas has been further defined by AHIC's creation of harmonized use cases that provide detail for each area. The EHR use case focuses on the ability to exchange laboratory results electronically. The PHR use case is focused on exchange of patient medication and allergy information. The biosurveillance use case includes exchange of medical facility and resource information, as well as reporting of anonymized patient clinical data to public health entities to establish trends.

The Office of the National Coordinator (ONC) has funded seven major contracts to support its goals. Four of these contracts are to consortiums that are developing prototypes of the National Health Information Network architecture, which would be used to link various local and regional health information exchanges into an interoperable national system. The fifth contract is for designation of standards, entitled the Health Information Technology Standards Panel (HITSP). The sixth is to create a certification mechanism for HIT, aptly named the Certification Commission for Health Information Technology (CCHIT). The final contract is designed to evaluate the legal-privacy-security climate across the country so that reconciliation of state and federal rules and regulations might occur to encourage further HIT deployment.

The activities of all of these contractors are in turn organized around and focused on the same harmonized use cases that are described above. For example, HITSP has three workgroups of its own working on data standards, concentrating on EHR, PHR, and biosurveillance issues. It should be obvious that the use cases are very important in defining the focus and scope of all of this activity.

This brings us back to a recent development of particular interest to emergency medicine. The AHIC EHR workgroup recently sent a formal letter to Secretary Leavitt and the broader AHIC membership, encouraging the creation of a formal Emergency Responder use case. This letter can be viewed at http://www.hhs.gov/healthit/documents/RecommendationLetter20060801.pdf.

The general recommendation is that an Emergency Responder use case is urgently needed. If AHIC goes on to develop it, emergency medicine will become one of the primary areas of emphasis for future federal HIT activities. The American College of Emergency Physicians' leadership has been advised of this development, and has responded by writing a letter to Secretary Leavitt suggesting that ACEP play a lead role in the development of this use case. The ACEP Informatics Section will undoubtedly be a very valuable resource as this activity continues. We will keep the section posted on further developments as they become available.

Back to Top


An Introduction to Web Services

Andy Boggust, MD

What is it?
A web service is a standardized way of sharing application functions across networks using web protocols and XML (Extensible Markup Language) messages. XML lets you define your own customized markup languages for different types of documents. This means that data can be easily exchanged, not only among humans through Internet browsers, but also among computers and information systems. More importantly, XML has been widely accepted as the universal language of choice for exchanging information over the Web and is a public format (not a proprietary product). As a result, individuals can develop new standards for specific functions based on XML or XML-based standards.

Web services have emerged as the standard of Web-based technology for exchanging information. Web services are modular, self-describing, self-contained applications that are accessible over the Internet. Based on open standards, Web services enable you to build Web-based applications using any platform, object model, and programming language that you desire. Functions provided by Web services range from the very simple to the very complex.

Where did all this come from?
A number of companies (IBM, Microsoft, WebMethods) developed the early models of remote Web services as long ago as 1997. Several proposals, including Simple Object Access Protocol (SOAP), have led to standards developed by the W3C and other industry groups.

Why bother developing Web services?

Here are five compelling reasons to use Web Services:

  1. Interoperable. Web services achieve a higher level of commonality than has previously been available. For developers, this means that the applications and services they build will enjoy a long life span. Web services permit the use of a vast array of clients-Java, C++, .NET, JavaScript, Perl, and so on.
  2. Easy to use. Using Web services, the business logic of individual systems can be exposed over the Web. Developers or business analysts can compose a custom, client-side solution to a particular business problem by combining the Web services that they require. Not only can Web services developers use their own programming language, but also their own component object model, architecture, and implementation strategy. As long as developers adhere to Web services standards, they can share functionality across the Web without knowledge of their target system's environment.
  3. Reusable. Because of the component-based model of Web services, they can be reused whenever necessary. Additionally, Web services can enable the extension of existing code so that it can be exposed over the Internet.
  4. Consumable by both humans and computers. Web services have been developed to be easily accessible by both humans and computers.
  5. Ubiquitous. Because Web services are provided over the Internet, they are accessible from anywhere and use existing infrastructure. Furthermore, because of the standards they are developed with, Web services respect existing security systems such as firewalls.

Security and simplicity. Since Web service messages travel as part of Internet traffic, they enter corporate networks easily. Digital signatures and secure HTTP ease authentication and data integrity concerns, but many companies will want additional safeguards. The simplicity of the standards helps integration, but to extend corporate systems, Web services must be able to address complex application issues like service guarantees and multiple phase transactions.

Acronyms in Action

What's the point of new technology if you can't invent some cool acronyms to describe it? Web services have plenty of them. Having already discussed XML, there are three other important technologies that you should be aware of:

  • Web Services Description Language (WSDL)
  • Simple Object Access Protocol (SOAP)
  • Universal Description, Discovery, and Integration (UDDI)

WSDL
WSDL is the metadata language of Web services. It acts as a user's manual for Web services, defining how service providers and requesters communicate with each other about Web services. Like XML, WSDL is extensible to allow the description of endpoints and their messages, regardless of what message formats or network protocols are used for communicating. WSDL can be used to design specifications to invoke and operate Web services on the Internet and to access and invoke remote applications and databases.

Typically, if you want to create an application that communicates with a particular Web service, all you need is that service's WSDL file.

SOAP
SOAP is an XML-based protocol for exchanging information in a distributed environment. It defines a mechanism to pass information between clients and servers. Like Web services as a whole, SOAP is independent of the platform, object model, and programming language being used.

A particular advantage of SOAP over earlier protocols is that it uses XML and is therefore text-based. This makes SOAP-based applications easier to develop. Additionally, text-based protocols like SOAP over HTTP are firewall-friendly and tend not to create the same security issues as proprietary protocols.

UDDI
UDDI is the meeting place for Web services. An information database of Web services, a UDDI registry stores descriptions about companies and the services they offer in a common XML format. Just as businesses list their products and services in a telephone directory, Web service brokers use this specification to register services that service requesters can then discover and invoke. Web-based applications interact with a UDDI registry using SOAP messages. Conceptually, the data in a UDDI registry can be divided into three different types of telephone directories: a white-pages section that provides business contact information, a yellow-pages section that categorizes businesses and services, and a green-pages section that provides technical information about the services that a business offers.

Where to Go for More Information

Although this has served as a brief introduction to Web services, you will undoubtedly want more information, and more importantly, to learn how you can begin developing Web services for yourself. There are many books (I recommend those from O'Reilly) on the subject. However, there are many online references and useful services available as well.

O'Reilly xml.com - http://www.xml.com/
Microsoft Web Services Home - http://msdn.microsoft.com/webservices/webservices/
World Wide Web consortium - http://www.w3.org/2002/ws/
Google SOAP Search - www.google.com/apis/

Back to Top


Human-Computer Interfaces in the ED: Part Three of an Ongoing Series

Keith Conover, MD, FACEP

In the first of this series, I tried to persuade you that your computer was human-illiterate, and we defined and discussed usability, memorability, and learnability. In the second, we discussed Tognazzini's Paradox: how the hardest part of designing an effective program is often what seems the most trivial—sometimes simply a matter of changing a single word.

Now we should discuss design integrity, and in particular, simplicity and abstraction.

Integrity is easy to identify, hard to explain. Let me give a few examples and make an attempt at explaining.

First, Frank Lloyd Wright. National and international associations of architects have acclaimed one of his houses the most important building of the 20th century: Fallingwater. (Google it—try Google Images—and look at some pictures.) Fallingwater, a house he built for the Kaufman family of Pittsburgh, is the finest example of his "organic" architecture. Wright considered organic architecture to be what is entirely appropriate to its place, its time, and its user. Having Bear Run go through the living room, and building the room out over the waterfall, sounds like an exercise in spectacle. Yet anyone who has been to Fallingwater (something I highly recommend—and while you're there, also visit his house Kentucky Knob, open for display about 10 miles away) can understand that it is actually a very understated house—there isn't a bit of spectacle. The irregular, staggered horizontal lines of the house mesh with the flat-bedded stone of the Bear Run ravine, and the house seems to be a natural extension of Laurel Mountain's bones rather than something imposed on the landscape.

I strongly recommend that your visit to Fallingwater also include a day-hike in the surrounding Bear Run Nature Reserve so you can get a feel for Pennsylvania's Laurel Highlands, the western edge of the Appalachian Mountains and a just lovely area to hike. But be prepared for wet weather—the top of Laurel Ridge to the east is. It's about an hour's drive from my house in Pittsburgh, which was the house and architect's studio of one of Wright's pupils, and its renovation takes more than all my time, effort, and energy, but it at least shows I truly buy into this "organic" idea.

This spirit of "organic" architecture, though it might seem a sideline, is central to the problems of good design for information display, and particularly for ED software. A look at what constitutes "organic" architecture provides important lessons for us.…organic architecture is honest – it does not lie about anything (therein lies its beneficence when we seek truth; its impudence when we practice hypocrisy). A material used represents itself and no other. Nothing appears to be what it is not. If a material looks like brick, it is brick. If a wall surface looks like tile, it is tile. If a panel looks like wood, it is wood. An asbestos shingle molded to imitate wood grain is not organic architecture. A wooden surface whose grain and quality is covered with paint is not organic architecture. A steel desk grained to look like wood is not organic architecture. –John Lloyd Wright, writing in My Father Who Is On Earth (about his father, Frank Lloyd Wright)1

Wright, in common with the Stickley brothers, furniture designers from the early part of the 20th century, eschewed applied ornamentation and shoddy products of Victorian mass-production. Wright talked of "constitutional ornament"—where the ornamentation was a natural or organic outgrowth of the construction itself rather than something tacked on later. The mortise-and-tenon joints of a Stickley Morris chair are a classic example.

While some of the British exponents of the Arts and Crafts Movement idealized the Medieval craftsman who built an object from scratch using the labor of a single person, neither Wright nor the Stickleys objected to machine-made items, only to shoddy machine-made items. Indeed, the Stickley factory in upstate New York, which is worth a visit, now has some of the most advanced furniture-making machines in the world.

To see examples, Google "Stickley," and check out www.stickley.com, as Stickley is still in business and still offers some of its turn-of-last-century mission-style furniture. And if you visit my house, you probably won't be surprised to find it full of Stickley mission-style furniture.

To find an example of applied ornamentation in current computer program design, simply find a PC that runs WindowsXP. Use the Search feature with its default settings. Take a careful look at the animated dog in the lower left corner.

To find a computer example of "constitutional ornament" is difficult. In computer design, constitutional ornament would be a screen where every single pixel has a function, but the overall structure and design of the screen is itself ornamental. Alas, good examples are hard to find; yet, one may with some justification point to some of the screens of Microsoft PowerPoint XP. When editing a slide presentation, one usually sees a slide in the center, and a sequential view of the presentation's slides in miniature along the left. And when one wishes to select another design template, one sees another set of miniature slides of potential designs along the right side of the screen in a "task pane." While not the computer equivalent of Fallingwater or a Stickley Morris Chair—that's year away—the design nonetheless provides a pleasing yet functional screen that may be considered, with its repeated grid of functional elements, to include constitutional ornament.

In their classic book Designing Visual Interfaces: Communication Oriented Techniques,2 Mullet and Sano describe the application of these and other graphic design principles to computer design group them under the rubric of "integrity." They identify several critical principles to the design of computer screens. In addition to showing examples of good and bad computer screens, they discuss integrity in other fields. Paraphrasing Wright and Stickley, they say that objects constructed from genuine materials are always valued more highly than those that use a cheaper substitute, providing a picture of Shaker built-in cabinetry for illustration. Attempts to make a computer program more user-friendly by adding an animated dog are as bad as "mission" furniture that is held together with staples, but emulates a Stickley mortise-and-tenon joint using a glued-on block of wood.

Mullet and Sano give examples of design integrity from other disciplines, including the kanban signs that adorn traditional Japanese shops. Shop owners devote much time and effort to the design of these signs, which traditionally embody the virtues of shibui (subdued beauty) and wabi (elegant simplicity). For the virtues of abstraction and simplicity in the graphic arts, they show the map of the London Underground. In this much emulated staple of graphics design classes, all rail lines are constrained to 45° angles, and outlying lines are compressed to show sequence but not distance. They suggest that to evaluate a program's screens, you should look for clues to poor design, such as explanatory text for what should be obvious by the screen's design, or the need for careful training to be able to use the program effectively. As Donald Norman, in his classic book The Psychology of Everyday Things (later reissued as The Design of Everyday Things),3 remarks about a door that has a pull-type handle with lettering saying "PUSH": "A door that requires a user manual, even a single-word user manual, is a design failure." Similarly, a program that requires a user manual is a design failure.

Enough for now. Next time, we'll start talking about "discount usability engineering." (Neilsen)

References

  1. Wright JL, Wright FL, Menocal NG, et al. My father who is on earth. New ed. Carbondale: Southern Illinois University Press; 1994.
  2. Mullet K, Sano D. Designing Visual Interfaces: Communication Oriented Techniques. Englewood Cliffe, NJ: Sunsoft; 1995.
  3. Norman DA. The psychology of everyday things. New York: Basic Books; 1988.

 


 

 

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.

Feedback
Click here to
send us feedback