I recently re-read an old essay by Clay Shirky (shirky.com) called In Praise of Evolvable Systems. It opens with a laughable description of designing a novelty protocol to slip past the IETF as a joke - however, the feature set described is an accurate description of the World Wide Web, as it existed when Shirky wrote the essay in the late 1990's. That lead-in ends with this:
HTTP and HTML are the Whoopee Cushion and Joy Buzzer of Internet protocols, only comprehensible as elaborate practical jokes. For anyone who has tried to accomplish anything serious on the Web, it's pretty obvious that of the various implementations of a worldwide hypertext protocol, we have the worst one possible.
Except, of course, for all the others...
It seems the WWW protocol family has turned out to be another example of "less is more", or more accurately, "broken is fixed".
Per Shirky:
The problem with that list of deficiencies is that it is also a list of necessities -- the Web has flourished in a way that no other networking protocol has except e-mail, not despite many of these qualities but because of them. The very weaknesses that make the Web so infuriating to serious practitioners also make it possible in the first place. In fact, had the Web been a strong and well-designed entity from its inception, it would have gone nowhere.
How is this possible? How did a bad protocol urn out so well, when so many well-thought-out protocols in so many domains have gathered dust?
The electronic world in other quarters was filled with similar visions of strong, well-designed protocols -- CD-ROMs, interactive TV, online services... each of these had the backing of significant industry players, ... as well as a growing user base...
These various protocols and services shared two important characteristics: Each was pursuing a design that was internally cohesive, and each operated in a kind of hermetically sealed environment where it interacted not at all with its neighbors. These characteristics are really flip sides of the same coin -- the strong internal cohesion of their design contributed directly to their lack of interoperability...
In other words, every contender for becoming an "industry standard" for handling information was too strong and too well-designed to succeed outside its own narrow confines. So how did the Web manage to damage and, in some cases, destroy those contenders for the title of The Next Big Thing? Weakness, coupled with an ability to improve exponentially...the Web's poorer engineering qualities seem not merely desirable but essential.
There are numerous examples of "Broken Is Fixed" phenomena. In the aerospace arena, the Mir Russian space station is paradigmatic. In the realm of standards, XML is in many ways a broken version of its predecessor, SGML, but few would dispute its utility or dominance in the realm of markup standards today. While many pundits tout its extensibility, I consider the key advantage of XML to be - for lack of a better word - intensibility.
I define intensibility as the ability of an entity to be simplified without losing essential functionality. Most transactional XML uses a minimal subset of the specification. The most popular framework for transactional XML right now is the SOAP/WSDL specification family, which has usurped the name "Web Services". I say 'usurped' because there are many ways to provide services over the Web, and the Web Services framework is far too cumbersome for many types of services. It is difficult to imagine using SOAP/WSDL in AJAX services, for example.
Paul Prescod has published a detailed analysis of the tension between SOAP and one of its more elegant competitors, REpresentative State Transfer or REST. When service providers on the Web have tried to switch from simpler protocols to Web Services, as Google did in 2002, developers have raised objections based on the unnecessary complexity of Web Services. Prescod put the issue of the debate very tersely: "The Google API uses no features of SOAP that are not more simply and easily availble through HTTP. " Google's more recent AJAX APIs are elegant and straightforward, as can be seen by right-clicking and choosing "View Source" on the demo page for their Hello World Search App.
Shirky gives us three rules for evolvable systems:
Evolvable systems -- those that proceed not under the sole direction of one centralized design authority but by being adapted and extended in a thousand small ways in a thousand places at once -- have three main characteristics that are germane to their eventual victories over strong, centrally designed protocols.
- Only solutions that produce partial results when partially implemented can succeed...Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen...
- What is, is wrong. Because evolvable systems have always been adapted to earlier conditions and are always being further adapted to present conditions, they are always behind the times. No evolving protocol is ever perfectly in sync with the challenges it faces.
- Finally, Orgel's Rule, named for the evolutionary biologist Leslie Orgel -- "Evolution is cleverer than you are"... it is easy to point out what is wrong with any evolvable system at any point in its life... However, the ability to understand what is missing at any given moment does not mean that one person or a small central group can design a better system in the long haul.
Centrally designed protocols start out strong and improve logarithmically. Evolvable protocols start out weak and improve exponentially. It's dinosaurs vs. mammals, and the mammals win every time.
Lessons for Healthcare Informatics
What can we learn from Shirky regarding healthcare informatics standards? Healthcare informatics faces a different situation than that faced by the designers of the Web, starting with Tim Berners-Lee. The innate complexity of the domain is several orders of magnitude in excess of what the designers of the Web faced.
We must deal with the same issues in terms of computer and communications science, though we have the advantage of being able to leverage their work with respect to communications at the data link, transport and session layer protocol layers.
In the realm of information science, we can leverage their work with respect to the structural syntax of document presentation. With respect to semantics, though, the healthcare informatics community is generally way ahead of the larger Web - not in terms of "final answers", perhaps, but at least we were wrestling with semantic issues long before Tim Berners-Lee kicked off the Semantic Web initiative. Arguably, protocols like the ICD family, SNOMED, and LOINC have found a workable balance between central control and evolvability, in the face of enormous domain complexity coupled with explosive semantic growth. ICD and SNOMED are diseased-focused, and LOINC attempts to describe primarily laboratory-based entities and activities; though centrally controlled, all are veery open to input from the field.
One area where the ICD and SNOMED initiatives have fallen short is in the realm of describing the volatile clinician-patient interface. The clinical encounter is characterized by vague complaints, wide variability in symptomatic descriptions, and the need to address non-disease-related issues such as the discussion of concerns over the potential side effects of immunizations or the relative benefits of diet versus exercise in recovery from severe cardiovascular events. In these areas, the International Classification of Primary Care Second Edition (ICPC-2) and the related interface standard, the Electronic Nomenclature and Classification Of Disorders and Encounters for Family Medicine (ENCODE-FM), have provided a flexible mechanism for data entry by ordinary clinicians at the point of care, while remaining translatable where appropriate into other health informatics protocols such as those named above.
ENCODE-FM and LOINC both provide explicit support for local extensions to the specification, extensions that can ultimately be absorbed into the standard. This gives them an edge over ICD and SNOMED in terms of evolutionary capability. This capability reflects different cultural motivations: wet-lab informatics is driven by the pragmatism characteristic of bench scientists, while family medicine informatics faces challenges inherent in the subjectivity of patient reports and locale-specific interrelationships between medicine, milieu, and social norms.
Translational Medicine is our greatest challenge
Translational medicine, in which basic life sciences discoveries migrate into the clinical realm, will greatly exacerbate the predicament faced by health informatics, due to a proliferation of new data elements and relationships equivalent in scope to the Cambrian Explosion.
Genomics, proteomics, and other emergent interdisciplinary molecular biomedicine domains are struggling to create ontologies, taxonomies, and controlled vocabularies that are sufficiently expressive to bridge domains without losing the semantic precision that has long characterized the basic sciences. As discoveries in these areas migrate into clinical research and ultimately into medical practice, molecular biology knowledge sources will need to be integrated with clinical and biomedical sources, initially in the research domain, but very soon thereafter into clinical operations.
Since the inception of automated data processing, biomedical informatics has made less apparent progress than other computational domains. This is not due to a dearth of talent or motivation, but rather to the broad scope and extremely complex and volatile nature of the problem domain. Despite our best efforts at centralized control, our ontologies and vocabularies inevitably fulfill Shirky's laws: they are always in production, always wrong, and always evolving. The one mistake we could make is to create standards that are not only extensible, but also intensible. They must work as well for applications unning on cell phones or in an implanted monitoring device as they do for the mainframe-hosted real-time operations systems of a quaternary care health center.
Only time will tell how well we can meet the challenges we face. We have indeed been born in an interesting time.
Comments