There is an invention you may have heard of, it’s called the telephone. It is a device that provides physical interoperability between individuals that want to communicate with one another. Assuming they both speak the same language and understand each other’s context, two individuals can share information using this device.
The first phone call was made by Alexander Graham Bell to his associate Thomas Watson on March 10th in 1876. The very first conversation was “Mr. Watson, come here, I want to see you,” which is ironic because he essentially said “get off the phone and come here.” But I digress.
People quickly saw the potential of this new technology and looked for ways to expand its use. To that end, roughly two years later the first commercial switchboard went into operation in New Haven Connecticut. Switchboards were devices that allowed two phones that were some distance apart to connect to one another. This was done with human operators that contacted one another and orchestrated the connection through facilities known as exchanges.
The implementation of the telephone expanded rapidly in the early 1900s. The number of telephones went from 239,600 in 1891 to 13,411,400 in 1920. The number of conversation that had to be managed through an exchange went from 1,585,000 per day in 1891 to 31,835,000 per day in 1920.
This expansion led to a great job boom for switchboard operators. These operators were typically women that worked for low wages and in sweat shop conditions ($7 per week, 10-12 hour days).
Approaching 1920, the vast majority of calls were still routed manually by human operators. This was becoming a problem, because the number of calls and the complexity of the routing were surpassing the available labor force. This began to impact both the quality and performance of the exchanges. It became clear to many in the industry that automation would be necessary to meet the growing demands.
Automation had been around, but had not been widely adopted. In 1888, an undertaker by the name of Almon Strowger bitterly suspected the local telephone operator of routing his calls to a rival undertaker, in an effort to drive him out of business. This enraged him to such an extent that he swore he would create a telephone system that would eliminate the job of telephone operator and cause calls centers to become extinct. His invention was the basis for the system we use today.
The largest player in the market, Bell Systems, initially refused to switch from manual systems. They felt that the automated systems presented too many technical problems, did not view them as faster or more valuable and most importantly, felt that the manual systems were necessary to continue their high level of personal service and justified the price to their subscribers. However, competition, cost savings and labor issues forced Bell to implement automation. In 1919 they began installing fully automated systems in large cities.
In the beginning automation was not well received. Having to dial the whole number, including the area code did not sit well with subscribers who resented having “to perform the duties of telephone operator in order to enjoy the benefits of telephone service.”
In 1920 only 2% of the telephones in the US were automatically switched. This number grew to 75% by 1950. Electronic switching, which was considered more reliable than mechanical, was introduced in 1968 and by 1988 75% of all telephone traffic was handled by electronic switching. In 1970 the telecommunications industry employed 421,000 switchboard operators annually. Today that number is about 78,000.
What’s the point?
Now, you might be asking yourself “Why did you choose to share that with me?” Here’s why.
Recently I was at a conference and there was a session being given by a well-respected vendor luminary about clinical mapping. It was an informative session that was essentially a mapping primer. I listened respectfully and thought they provided good advice about planning your mapping project, understanding the intent of the map, etcetera. But there came a point in the questions and answers when the session veered off the tracks for me.
It was about one point in particular, when the speaker said essentially “Never employ automated mapping.”
Now, in the interest of transparency, I should point out that Clinical Architecture has a product called SYMEDICAL® Server that does a great job of automating interoperability, so I may be biased. I should also invert the transparency and mention that the speaker, and many who share his sentiment on mapping, are in the business of, you guessed it, human-powered mapping. So who do we believe?
I believe that you can’t completely trust automated mapping. Does that surprise you? I also happen to believe that you can’t completely trust human-powered mapping either. We built SYMEDICAL® Server in part because we saw what the last ten years of human created mappings have gotten us with a fairly limited set of interfaces even using maps. There are great clinical mappers out there... but there are also some that are less than great. Interoperability is really about the management of uncertainty. This is because neither the algorithm, nor the human, can completely understand the mind of the “author” of the original information. The best we can do is get close enough to be helpful, raise awareness and support the decisions of a qualified healthcare professional.
However, if we can get close and have mechanisms to manage uncertainty, then we should do our best to assemble what we can. If you agree with this statement, and are a student of history, then I would submit that you must agree that automated mapping is inevitable. Why? The numbers, that’s why.
There are roughly an estimated 5754 hospitals and 161,200 medical practices in the United States. In 2009 there were 36.1 million inpatient discharges, 110 million clinic visits, 124 million emergency room visits and 956 million physician office visits. We are expected to be able to exchange information from these islands of data, among others, across multiple clinical, administrative and demographic domains for countless number of patient interactions. These channels of streaming data will include standard, commercial, local and free text terms that need to be reconciled in each of these systems, normalized into clinical repositories and routed to government agencies.
The history of the switchboard operator is a rough parallel for where we are today in exchanging healthcare information in many ways. But the similarities fall short in a few places. Back then they had a large cheap labor force to throw at the problem and forestall the inevitable. They were also only dealing with physical interoperability, which is easier (at least today) than semantic interoperability. In our case the problem is difficult, the time is short and resources are far from cheap and plentiful.
If you agree that you can’t automate mapping, then how many terminology mappers do we need to babysit all of these places where data needs to be mapped? What do we do when a map fails or the term associated with a code changes in real-time? Do we wait for the next review of the map at the end of the month or in six months? How much will it cost to have a terminology mapper watching each channel (assuming we have enough humans to throw at the problem) and what are their qualifications when we are mapping various domains (medications, lab results, problems, procedures, microorganisms, etc) ?
I am concerned that we cannot address this problem with human mappers alone and that if we try, the next generation of clinical repositories will be filled with junk before we realize it. And if that happens, we will have lost precious time and credibility.
The answer is automated systems that not only try to map, within their configured limits, but monitor the map and alert their human counterpart when they encounter uncertainty. This is a path that we can take by degrees, evolving step by step, protecting our precious human resources.
I have a lot of respect for the speaker at the conference. But I believe that resistance is futile and the sooner we embrace automation the sooner we can start to evolve it and make it better.
If you agree or disagree, I value your thoughts. Feel free to share them in the comments.