Future of Health IT: Trends and Scenarios

Agile Methodology and the Conversational Meta-Methodology: Part two

In my earlier post, I expressed some reservations about Agile methodology (or possibly, about misapplications thereof, I'm open to persuasion).  I introduced the Conversational Meta-Methodology as an antidote to the problems cited in that post. My rant continues here with a different problem I'm seeing very clearly in my current project.

I'll repeat an important clarification from the earlier post briefly: my current project doesn't appear to be failing at all, in fact I think it will result in a kick-ass product, and the part of the product that will be of greatest ultimate import is the component where the Agile approach (and the Conversational Meta-Methodology) have been followed most religiously.  The problem I'm describing here is one that, if it were overcome, would have resulted in "kicking it up another notch", as Emeril would say.

In twenty-five years of commercial and enterprise product development, I have worked on many systems that can be viewed as distributed data repositories, or more generally, distributed resource frameworks that may encapsulate both data and behavior. Application of best-practices software engineering principles leads to a more-or-less standard architecture for such systems, in effect a high-level architectural design pattern.  It consists of the following components:

• A query front-end, in which the end user (human or machine) expresses queries in some abstract query language, and receives results rendered in some desired output data structure. 
• A controller, responsible for partitioning the work to be done, dispatching subqueries to remote data sources (workers) in parallel, monitoring their progress and reporting progress to the front-end, aggregating results received from the remote nodes in some standard format, performing aggregate transformations on the composite result set, rendering the aggregate results into the desired output form, and returning the results to the front-end. The controller also provides graceful degradation in the event of exceptional occurrences, such as a remote node being unavailable or receipt of a malformed query.
  Another common but by no means universal function of the controller is to provide a master entity index, to identify real-world entities represented in multiple remote data stores and provide a common unique identifier for such entities.
• Remote end-point adapters that can map the abstract subquery it receives onto the local data store(s), retrieve data, and translate as needed into the standard format employed by the controller. The adapters can provide a wide variety of additional functions, such as deidentification, performing local aggregate functions on their result set, or running procedural code that processes or even generates local data.

DBMS developers, database architects (DBAs) and others will recognize how this pattern describes the internal structure of an enterprise DBMS. The remote data stores in the above description may be different schemas in the same database, different database instances, or simply ad hoc algorithms that can be delegated to worker threads in order to parallelize query execution on a single local data store.  The abstract query language is SQL if the database is relational, and the aggregate operations are stats functions, grouping, sorting, and so on. The adapters may do sorting and the controller does a merge of sorted results. It's all pretty familiar stuff.

Here's a diagram that shows how this applies to the architecture of a DBMS. There are a lot of variations on this theme, but the picture holds for the DBMS I have worked with over the years. Click on the picture to open full-size in a new tab or window.

In a DBMS, the subplans are queries against various data storage resources -- tables, indices, and so on -- as specified in the retrieval aspect of the overall execution plan. "Develop execution plans" covers a lot of ground, since this is where rocket-science algorithms like cost-based optimization are applied.  Of course this diagram only looks at the query side of a DBMS (the "U" in "CRUD"), but the picture is not overly different for updates and deletes, or even for DDL operations that affect the metadata (aka data dictionary tables in a DBMS).  The "Group and order" and "Perform aggregate transformations" boxes are often interdependent and may occur in a different order than shown here, depending on the transformation plan. Nonetheless, I would maintain this is a reasonable high-level view of DBMS architecture, and it conforms well to the pattern described above.

To make it more specific to this blog's readership, the diagram below shows a healthcare-specific instance of the pattern (click to open full-size in a new window). What makes it healthcare-specific is the Honest Broker with its Master Patient Index for HIPAA compliance. The ontology mentioned in the diagram represents the problem domain for the purpose of formulating abstract queries and structuring results, and therefore is a lot like a cross-enterprise data dictionary, a syntactic data model. If it is a true ontology, though, it overlays semantics on the syntactic structure and can be used for reasoning activities.

Driven to Distraction - At 60 M.P.H., Office Work Is a High-Risk Job - Series - NYTimes.com

On Wednesday, the Transportation secretary, Ray LaHood, called the broader phenomenon of distracted driving a “deadly epidemic” at a meeting on the issue in Washington. Real estate brokers, pharmaceutical sales people, entrepreneurs, marketers and others say they have little choice but to transform their cars into cubicles. In this merciless economy, they say, they have to make every minute count, and respond instantly to opportunities and challenges.

And they argue that the convenience of constant contact — and the chance to tick off items from an endless to-do list while driving — far outweigh what they think are slim chances that it could lead to a wreck.

via www.nytimes.com

The NY Times has been running a series on the perils of multi-tasking while driving. Today's installment highlights how work pressures, often self-imposed in the case of knowledge workers, are causing people to kill themselves as well as innocent bystanders through stupid mistakes made while trying to be on the telephone, send email, and drive all at the same time (or similar combinations of ICT activities).

It may be that in our culture, this pattern of behavior is Darwinian natural selection at work, though the loss of innocent bystanders doesn't quite fit the pattern. It does represent a continuation of the obliviousness we feel with respect to the dangers of multitasking. In addition to this kind of life-threatening danger, there are less obvious but more pervasive effects. In a paper published earlier this year in PNAS Early Edition, "Cognitive control in media multitaskers", Ophir and colleagues described a controlled behavioral trial in which they showed that media multitasking degrades personal productivity and effectiveness:

A trait media multitasking index was developed to identify groups of heavy and light media multitaskers. These two groups were then compared along established cognitive control dimensions. Results showed that heavy media multitaskers are more susceptible to interference from irrelevant environmental stimuli and from irrelevant representations in memory. This led to the surprising result that heavy media multitaskers performed worse on a test of task-switching ability, likely due to reduced ability to filter out interference from the irrelevant task set.

In all likelihood, many of us in the knowledge business will be as oblivious to this evidence as we have been to the numerous past studies of the dangers of using cell phones while driving. Sad, but true, I fear.

Agile Methodology and the Conversational Meta-Methodology: Part one

I'm involved in a project that uses an online Agile project management system. It's not a big project in terms of number of participants, but the personnel are distributed across four institutions in three different states, none closer than a hundred miles to any of the others. When it becomes manifest, it will be a major achievement in the world of biomedical research, and it may result in technologies with commercial potential, even though they will be delivered under an Open Source license.

As stated in the opening sentence, the project employs the Agile approach. It's the first time I've worked on a project branded as Agile. I'm capitalizing the word to distinguish it from the adjective "agile", because the methodology may be Agile, but that does not guarantee Agile projects are agile in practice.

---

I should say up front, in case any reader knows the project of which I'm speaking (and I'm sure some will), the project is moving along nicely. It has its ups and downs as with any project, but it is on track to be successful.

My critique here is directed at how the Agile approach as we are practicing it is getting in the way of the project approaching its full potential, which potential is well beyond the contractual scope as originally defined. The limitations I'm describing here could easily cause a different project to fail, but that isn't happening on my project. I'm happy with it, but I could be happier.

---

The problems I'm seeing with the Agile approach may relate to subtle misapplications of the Agile approach in projects involving distributed teams, and I suspect these are widespread in the industry. These problems stem from tacit cultural biases and preferences.

I say 'misapplications' because people I respect and admire are ardent Agile enthusiasts: for example, long-time friend and colleague from my commercial product development days, Rich Sheridan of Menlo Innovations. If Rich says it works for projects like mine, and he does, I know I have some learning to do. I'm still at odds with his viewpoint at present, but I know I'll probably be convinced.

An example of the kind of tacit cultural bias to which I'm referring is the tendency of software engineers to want someone else to talk to the end user. This is not at all due to laziness or indifference. Often shy and introspective by nature, most productive when left alone in silence, software designers and programmers often believe that the process works best when there is someone who can tell them what needs to be done, and then leave them alone to do it. There are often organizational policies that proscribe developer conversations with end users, and these factor into the equation as well.

This in turn is related to a more pervasive cultural bias, the assumption that intellectual constructs like the requirements or design for a product can have persistent, stable existence independent of the minds of the stakeholders (most importantly, the customers, sponsors, and implementers).If they did have that sort of stability, requirements could be written down and "thrown over the wall" as the saying goes.

Some projects must force this level of stability, for systems engineering reasons -- the software for the NASA Shuttle is an example -- but for most projects, requirements are fluid and dynamic, and worse, are never the same from one stakeholder's mind to another even at any specific point in time. Moreover, this fluidity is not limited to requirements analysis: the same can be said for detailed product design.

I'm not against creating requirements and design artifacts, whether in Agile user stories, in IEEE-standard formal documents, or UML models, as long as everyone who matters in the process understands that the documented version is always incomplete, always wrong, and never incomplete or wrong in the same way twice, i.e. at any two points in time during the life of the project.

In project management, the saying goes, Plans are nothing, but planning is everything"; I would paraphrase that here as "Requirements documents are nothing, but the requirements analysis process is everything."

To see the fallacy in the assumption of stable, documentable requirements, recall the cliched party game "Telephone". One person starts with a somewhat lengthy and usually gossipy anecdote, and whispers it into the next person's ear. That person whispers it into the next person's ear, and it proceeds in this sub-rosa serial fashion until the story has been told to everyone at the party. At the end, the last person recites out loud what the story has become in the series of translations, usually to the merriment of all present.

The telephone game metaphor in software development produces something like the ubiquitous "What the Customer Wanted" cartoons, an example of which is shown here, stolen from Allan Jardine's blog (click to open full-size in a new window):

 

The lesson of the Telephone game is that communication often happens without comprehension. When done well, projects using the Agile approach should be characterized by lots of communication.It is the ongoing conversation, not the artifacts, that ensure a successful project.

For that reason, when I listen to any software development methodology, I look for the points where meaningful conversations will occur. A 'meaningful conversation' in this context is a timely and thorough conversation about product and process that builds and continually refreshes a shared mental model of the vision, mission, and goals of the project -- a mental model that all participants acknowledge will evolve over time.

If these conversations occur throughout, involve all relevant stakeholders at their points of occurrence, and form the real basis for the collaborative work, the methodology will result in a successful project, barring the occurrence of any of the political, financial, and other disasters that can kill even the most promising efforts.

Rich Sheridan agrees with my premise that we were doing Agile development back in 1986 -- in fact, all the successful commercial projects we knew about used some methodology that would fit into the Agile paradigm. What we lacked was a trademarked brand wrapped around a coherent description of some incarnation of our "methodology". Rich learned that lesson well, and his group has registered a trademark for the term High-Tech Anthropology®. Menlo peddles a methodology, to put it crassly, but it's no con game -- what they teach you is eminently workable in practice, and I highly recommend their services.

That said, I think Rich would agree that their flavor of the Agile approach works as well as it does because it is an incarnation of what I will now name the Conversational Meta-Methodology, rather than as a result of any rote technique that they teach you. In fact, one of the things they will teach you is that all the rote techniques are intended to do is to work toward a shared mental model of the project as it evolves over time. It's the process, not the artifacts, that are the key to success.

To disclose my personal interest in this matter, I wrote a book back in 2002-2003 called Design Conversations: Envisioning Content-Rich Enterprise Systems. It's as much about requirements analysis as it is about design. I've gotten great feedback from many of the several dozen people who have read it (including a few who downloaded it to their Kindles), but it hasn't started a movement. Maybe it's time to trademark the Conversational Meta-Methodology^TM, write a manifesto, work up some curricula and a YouTube video or three, and found an institute of my own. :-)

I'll come back to this in a soon-to-be-written post and show how it relates to my current project.

The future of computing and communications: random thoughts, part 5

The New Scientist recently published an article entitled "Cell phones could be used to build 'audio Internet'". (I'm not sure if the article requires a subscription to obtain full access, and I apologize if it doesn't, but the link should at least lead to the abstract in that case.) This is one more indicator of the proliferation of modalities for human-computer interaction (HCI) that has been a major theme of my random thoughts in recent months.

The spoken web is an attempt to bring the power of the internet to rural India. Despite India's highly touted knowledge economy, around 70 per cent of its billion-strong population lives outside its cities, and most of them earn just $4 per day or less. And even for those who can afford computers, attempting to access the internet remains a futile exercise, either because they cannot read or write or the information on the web is simply not relevant to them.

The answer, says Tapan Parikh of the University of California, Berkeley, is speech. "An audio format would provide much more access and opportunity for local people to contribute," he says. "While a farmer may not be able to write a memo, or an email, or a summary of his work, he can easily talk about it."

Between a quarter and a third of India's one billion-plus population have access to a cell phone, with the number growing at 8 million per month. This is far greater penetration than the World Wide Web in India, especially in semi-rural and rural areas. Moreover, the content of the Web is not useful to India's poor, either (or both) because they cannot read or the content is irrelevant to their daily lives.

So how to leverage cell phone technology to bridge the Digital Divide? The answer posited by the New Scientist article is the spoken web.

...Conceptually, the spoken web is a network of VoiceSites, just as the internet is a network of websites. A VoiceSite can only be accessed by a phone, and only requires the user to be able to speak and listen. Callers can create their own VoiceSites or access those of others. They can also surf the spoken web, jumping from VoiceSite to VoiceSite using speech.

In developing the system, the team took their cues from the growth of the internet. "The thing that really fuelled the adoption of the World Wide Web is the ease with which you can create websites," says IBM IRL's Amit Nanavati. So they focused on developing a simple way to create VoiceSites.

Say a plumber wants new customers. First he calls a number and software called VoiGen then guides him, in his local language, through the process of setting up a VoiceSite. Relevant information, such as a welcome greeting and the plumber's contact details are recorded. Behind the scenes, the VoiGen system then creates a VoiceSite. A phone number, analogous to a URL, is then assigned to the plumber.

Anyone who calls the plumber's VoiceSite number is greeted with his welcome message, and then given help to navigate the information. For example, the caller can say "address" to hear the plumber's address, or "appointment" to request a call-out with him.

Conceptually, the spoken web is a network of VoiceSites, just as the internet is a network of websites. A VoiceSite can only be accessed by a phone, and only requires the user to be able to speak and listen. Callers can create their own VoiceSites or access those of others. They can also surf the spoken web, jumping from VoiceSite to VoiceSite using speech.

In developing the system, the team took their cues from the growth of the internet. "The thing that really fuelled the adoption of the World Wide Web is the ease with which you can create websites," says IBM IRL's Amit Nanavati. So they focused on developing a simple way to create VoiceSites.

Say a plumber wants new customers. First he calls a number and software called VoiGen then guides him, in his local language, through the process of setting up a VoiceSite. Relevant information, such as a welcome greeting and the plumber's contact details are recorded. Behind the scenes, the VoiGen system then creates a VoiceSite. A phone number, analogous to a URL, is then assigned to the plumber.

Anyone who calls the plumber's VoiceSite number is greeted with his welcome message, and then given help to navigate the information. For example, the caller can say "address" to hear the plumber's address, or "appointment" to request a call-out with him.

The vast majority of people on this planet are poor and illiterate, but more and more of these folks are acquiring access to cell phones, partly due to initiatives like GrameenPhone, but mostly due to the fact that cell phone infrastructure is profitable even in developing countries, in turn due in part to compelling economic reasons to want telephone access.

One example: I have read accounts of fishers in Kerala, one of India's poorest states, using cell phones to find out where to get the best price for their catch, eliminating their dependence on a single local bulk buyer. They can learn the price at various ports within sailing distance and mentally compute the tradeoff between the cost of traveling to a given port and the value of their catch at that port. A classic reduction of market friction.

Clay Shirky wrote an acerbic commentary 2002 on the tendency to sentimentalize the "digital divide". In Half The World, Shirky wrote:

Because wireless infrastructure does not require painstaking building-by-building connectivity, nor is it as hampered by state-owned monopolies, it offers a way for a country to increase its telephone penetration extremely quickly. By 2001, there were 25 countries where cell phone users made up between two-thirds and nine-tenths of the connected populace. In these countries, none of them wealthy, a new telecommunications infrastructure was deployed from scratch, during the same years that keynote speakers and commencement invitees were busily and erroneously informing their listeners that half the world had never made a phone call.

This shift suggests that characterizing the "digital divide" in terms of access to broad- and wideband connectivity is naive. The power a cell phone provides to a poor fisherman is impressive, as one can see from this quote from a 2006 Washington Post article:

Rajan said the dealers don't necessarily like the new balance of power, but they are paying better prices to him and thousands of other fishermen who work this lush stretch of coastline. "They are forced to give us more money because there is competition," said Rajan, who estimated that his income has at least tripled to an average of $150 a month since 2000, when cellphones began booming in India. He said he is providing for his family in ways that his fisherman father never could, including a house with electricity and a television.

The spoken web could extend the leverage described by this fisherman to myriad small businesses and to individuals in the general population of the developing world. As with the World Wide Web in its infancy in the early '90's, it is impossible at this point to imagine the potential of the spoken web.

Another question: when high-bandwidth connectivity does reach into regions where the population is largely illiterate, will we see the emergence of an audiovisual web, which could merge the spoken web with multiple visual and audio media? Only time will tell, but the possibilities are not remote: in India a little more than a decade ago there were no cell phones, and Web-enabled multimedia cell phones were a pipe dream. Wherever a cellular network exists now, the potential for a 3G/4G Web-enabled cellular network already exists. Unless a better technology emerges in the interim, an audiovisual web targeted at semi-literate and illiterate population segments seems to me to be inevitable.

BBC NEWS | Virtual health care gets UK trial

You can read about the Aberdeen Royal Infirmary's venture into the brave new world of virtual healthcare in the  BBC News article entitled Virtual health care gets UK trial.Here's a taste:

Cutting edge telemedicine technology, that will allow medical staff to offer "virtual" health care, is being trialled at Aberdeen Royal Infirmary.

HealthPresence, a system developed by Cisco, links up doctors with patients through a video conferencing booth.

Blood pressure, temperature, pulse rate, weight and lung function can be assessed at a distance in the booth if patients can not make appointments.

If the trial is successful, booths may be set up in locations across the UK.

Possible future locations for the mobile health suite could include schools, workplaces, shopping centres and even people's homes.

(picture from BBC news story)

This trial uses kiosks manned by a human attendant; the kiosk can administer simple diagnostic tests, in addition to providing audiovisual teleconferencing. The presence of the human attendant goes a long ways toward allaying my fears about patient data security.

While not exactly a groundbreaking innovative concept, the Aberdeen trial is one of the first uses of rich Internet-based telecommunications media in the mundane world of primary care. I'm excited to see it, especially on behalf of my less well-off rural relatives and friends who currently have limited access to high-quality healthcare.

Now, if we could only get them health insurance coverage... :-)

Microsoft Explains HealthVault Strategy

I didn't get around to writing about this at the time, but a couple weeks ago I read in eWeek about how Microsoft Explains [its] HealthVault Strategy. There are a couple of analogies I wouldn't have made myself: MS compares HealthVault to XBox and PayPal.

The goal was to provide ways for consumers to better understand their health and health information and manage that information for themselves.

Conn [Grad Conn, Healthcare and Life Sciences senior director for global consumer strategy] explained that with consumers as the aggregators and the controllers of to whom, how and when their information can be shared, the traditional health information model is turned on its head.

"Right now, the mechanism for this is through HIPAA, which dictates how to control patient privacy when patients don't control the records," Conn said. HIPAA, he said, has very clear rules that patients can request to see, copy, add to or delete any piece of health information in their record, and HealthVault uses those same procedures, but in a digital format.

So far so good. This (when properly implemented, whether by Microsoft, Google, or some other "fourth party") will accomplish in nimble form what is already one of the clumsiest and least effective of the HIPAA provisions, the portability requirements. Your health records are indeed available to you as a patient, but the care provider has the option of charging you for the cost of making a copy, and in virtually all cases will only supply the records in hard-copy format, even when an underlying EMR or EHR is in use.

Now, on to the first of the startling analogies:

"Better Than Free": Lessons for Open Source healthcare software systems

In The Technium, Kevin Kelly's "Better Than Free" post should be a wake-up call for Open Source project leaders, in particular those in the healthcare arena. I first got wind of his post via The Edge, and when it popped up again in Seth Godin's blog, I had to stop and take a look.

This super-distribution system [the Internet] has become the foundation of our economy and wealth. The instant reduplication of data, ideas, and media underpins all the major economic sectors in our economy, particularly those involved with exports -- that is, those industries where the US has a competitive advantage. Our wealth sits upon a very large device that copies promiscuously and constantly.

Yet the previous round of wealth in this economy was built on selling precious copies, so the free flow of free copies tends to undermine the established order. If reproductions of our best efforts are free, how can we keep going? To put it simply, how does one make money selling free copies?

I have an answer. The simplest way I can put it is thus:

When copies are super abundant, they become worthless.
When copies are super abundant, stuff which can't be copied becomes scarce and valuable.

When copies are free, you need to sell things which can not be copied.

Well, what can't be copied?

A great question. Fortunately, Kelly has an answer ready, though I think he left out one important point.

IEEE Spectrum: Visualizing Electronic Health Records With "Google-Earth for the Body"

I haven't much time to write today, but I absolutely had to let you know about this article from the January issue of IEEE Spectrum: Visualizing Electronic Health Records With "Google-Earth for the Body":

Andre Elisseeff leads a research team at IBM’s Zurich Research Lab that in September demonstrated a prototype system that will allow doctors to view their patients’ electronic health record (eHR) using three-dimensional images of the human body. Called the Anatomic and Symbolic Mapper Engine, the system maps the information in a patient’s eHR to a 3-D image of the human body.

There's more...

Unified Communications: The Next BIG Thing in Healthcare | Bill Crounse, MD | Channel 10

The future of health IT is everywhere (at least, intimations of it). Keeping up with it is not easy. I found the post discussed here a while ago in Dr. Bill Crounse's blog at Microsoft. It's called Unified Communications: The Next BIG Thing in Healthcare. I have a bunch of these posts that are partly done, and I'm trying to work through the backlog. There's interesting stuff here.

Healthcare is a communication intensive business. Good communication has a profound effect on the quality and safety of patient care. Communication also has a huge bearing on patient satisfaction. Yet historically, the options for how we communicate with each other in the healthcare industry have been somewhat limited. We are hampered by an industry that has far too long relied on old fashioned telephone, paging, fax, and mail (both postal and interoffice); not exactly the most contemporary communication infrastructure.

This makes me realize how spoiled I am working at one of the top academic health centers. Email is the ubiquitous communications medium here, but we also use MSN Messenger (replete with voice, video, file transfer, and application sharing); Skype (which can do many of the same things); blogs, wikis, and integrated Sakai-based collaboration and communication environments; issue tracking and project management software; and of course all this is in addition to our enterprise and departmental IT and telecommunications systems. Did I mention clunky old pagers, which most of us avoid, opting instead for text messaging each other's cell phones when we need to.

The Future of Leadership - The Enabler

CIO Insight recently provided some insight into where biomedical informatics is heading in an article entitled The Future of Leadership - The Enabler.  It tells the story of Sandy Aronson, Director of IT for the Harvard Medical School–Partners Healthcare Center for Genetics and Genomics.  He's wrapping up an advanced degree, not in computer science or business management, but in molecular biology. 

It's not often that an IT professional earns an advanced degree in an entirely unrelated field for the sake of his job. But to Aronson, it makes perfect sense. "As IT professionals, it's really important to understand the content area we work in with as much depth as possible," he says. "You need to understand the non-IT processes you are working to support, so you can play a positive, efficient role in the process." For Aronson, that process isn't just about cutting costs or improving productivity. Aronson's group supports a user base of more than 600 researchers, scientists, technicians and healthcare professionals, all working on genetic-based healthcare, a concept that could re-write the rules of modern medicine.

I understand totally where Sandy is coming from. My own Master's, which I'm inches from completing now, is in information science with a focus on Human-Computer Interface. I've learned a lot, but in the meantime I've been helping to maintain existing and design new clinical research informatics systems. I've had to learn continuously about many things there - HIPAA; the Common Rule for the protection of human subjects; 21 CFR Part 11 and other aspects of the FDA's Good Clinical Practice predicate rule as they apply to computer systems; information security; the culture of a major academic health center; clinic and laboratory practice; and even a smattering of biology and medicine.

I'm betting Sandy's experience is similar. No matter what you study in school, there is so much more to healthcare informatics that no single course of study is going to provide all the knowledge you will need.

It's an exciting time to be in biomedical informatics. I've written about the synergistic convergence of multiple disruptive information technologies in my Rogue Wave scenario paper, and this field exemplifies perfectly the characteristics of the convergence.

Disruptive technologies are uncommon but not rare. The twentieth century witnessed the birth of numerous such technologies. The major events of the past twenty-five years in the world of IT have been the result of the ascendance of two different disruptive technologies about a decade apart. The first disruptive technology was the introduction of the personal computer and in particular the IBM Personal Computer and Microsoft’s DOS operating system in the early 1980’s. The second was the emergence of the World-Wide Web in the early 1990’s. Each of these changed the face of life in the advanced economies of the world in ways most of us would certainly call significant. Yet the changes we have thus far experienced pale in comparison to what the next four years hold in store. The reason: as we stated earlier, what we are about to experience is not just another emergence of a single disruptive technology, but the synergistic convergence of multiple disruptive technologies.

What do we mean by “synergistic convergence”? Synergistic convergence means the technologies harmonize, their disruptive forces melding in additive fashion. Rather than mitigating the effects of each other, their energies join just as the energies of the sea combine to form the rogue wave.

Information technologies are by definition enablers for other technologies, which on the surface may not appear related to IT. I used to work in the automotive industry, and what I saw there was that IT was a pervasive influence, affecting the processes of design, manufacturing, and sales, and enabling better and faster diagnostics in the service bay.

This picture is very incomplete, of course.  A modern automobile typically has multiple local-area networks embedded in it, with almost every dynamic aspect of the vehicle's operation under computer control.  High-end vehicles are beginning to use information technologies like Doppler radar to implement adaptive cruise control, and can communicate by satellite with monitoring systems that respond instantaneously to events like extremely sudden stops and the deployment of the vehicle's air bags.

Modern automobiles are complex beasts, but any single organ in the human body is orders of magnitude more complex, operating under the dynamically adaptive control of genomic, proteomic, and metabolomic information systems (technologies?). Aronson's academic studies have no doubt provided him (directly or indirectly) with insights into the ways in which such systems can be represented and simulated.  Even if his work is in the mundane arena of data processing that is used to manage clinical or basic science research operations, this knowledge will pay off.

I'm glad I focused on HCI, having seen how abysmal are even the best user interfaces in research and clinical IT, but if my budget and my wife will allow it, I can foresee further education in my future. It may focus on the complex knowledge domains on which Sandy has focused in obtaining his Master's degree. On the other hand, there are equally complex challenges in better understanding the cultural and socioeconomic dynamics operating within and between healthcare research organizations. It's a difficult choice.  The Chinese curse applies: we have indeed been born into an interesting time.