capstone slide 2

My Quantitative Biomedical home-page.

My web logs:
Perspectives in Public Health


Systems Thinking in Public Health

Other links:
Intelligent Agent Infrastructures For Supporting Collaborative Work (Sen, Durfee, and Schuette, 1995 - Computer Science and Engineering graduate project, EECS department, University of Michigan)

Evaluation of Blogger. Ching-I Chang. Narayan Kansal. Younah Kang. Wade Schuette. SI 689 (Computer-supported Coooperative Work, UM School of Information graduate program Group Project. December 13, 2005. )

Evaluation of Blogger - powerpoint presentation.

Biographic:

I inherited my interest in computing from my uncle, Roger Schuette, who is shown in slide 6 in a publicity photo from 1952 (roughly), which shows the computer his team had just designed and built at the Barber-Coleman Company in Rockford Illinois. Unfortunately, Howard Coleman's genius at invention wasn't matched with his insight into business, and the company decided these "computers" had too many bugs to ever amount to much, and sold their patents to other companies, such as, I think, IBM.

In any case, I built my own first analog computer, from a kit, in 1956 - it played Tic-Tac-Toe and would always either beat you or tie the game, depending on who went first. I was trained in the language "1401 Autocoder" at IBM in Cleveland, Ohio, in1965 while working for the Thompson Ramo Woldridge company, which became today's TRW.

In 1976, I got my MBA and joined a team at the New York State College of Veterinary Medicine and the NYS Diagnostic Laboratory that copied the Electronic Medical Record system developed by G. Octo Barnett at Massachusetts General Hospital, written in a new language called MUMPS, and converted it to handle multiple species. The work was led by John Lewkowicz, (The Complete MUMPS: An Introduction and Reference Manual for the MUMPS Programming Language, John Lewkowicz) , and was part of what led ultimately to the current largest medical records system in the USA, the Veterans Administration system VistA. (Veterans Health Information Systems and Information Architecture, with a name that precedes Microsoft's use of the name for their own operating system, no relation.)

We had the animal hospital up with sub-second response time, 80 functions - admissions, discharge, billing, histopathology slide indexing, decision-support for medication orders, etc. - fully implemented in 1976.

In 1976, we all thought that human hospitals were going to be just a few years behind us in putting in Electronic Medical Records systems. Given 30 years perspective, I think that was optimistic.

My major lesson, however, is that "There is no such thing as a technical problem." The technology to build entire EMR systems has been available for 30 years. The designs are freely available from the VA system, or from the state-run national health service in the Netherlands, to name two. The impedance, reluctance, resistance to implementation of such systems is not due to money, because we did the whole thing in 2.5 years with a team of 5 people, technically.

The issues hospitals have are psychosocial issues, often perceived as "political" issues, or discovered with shock and awe by yet another technical team as "implementation" or "acceptance" issues, which were mistakenly thought to be "minor issues" or "bumps in the road to be dealt with as they arose, at the end of the project."

After 30 years watching this field, I'd go the other way and say these are psychosocial issues and the technology is the trivial part. A standard laptop today has more computing power than we used to run an entire hospital system in 1976, or than the Netherlands uses to run a gigantic 2,500 bed hospital with sub-second response time. (in 1989 at SCAMC in San Francisco I had lunch with their chief developer - they were running a hospital on one "MicroVAX", with a second one as a hot-spare, and power left over. Of course, they had to rewrite the operating system to do it...)

Of course, no technology group wants to "hear" the message that the shoals they are crashing on are social in nature and that their whole concept needs to be rethought. The good news is that there is a growing body of expertise, in places such as the School of Information at the University of Michigan, in "social computing" - now an official graduate major at UM, which has a 30 year background in "Technology-Mediated Collaboration".

The design features of collaborative software are so different from those of single-user software, such as a spread sheet or word processor, that the old insights about software design and evaluation are worse than valueless - they actually lead you down the wrong pathways. Software that looks great when one person tests it in isolation, and has a good "human interface" (for 1 human) can still have a wretched "multi-human interface" behavior.

The national CCHIT approval process for medical record systems doesn't even begin to assess this level of this multi-level problem, but you can be sure that the hospital staff will experience that level and respond to it. You can also be confident that, if this level wasn't consciously and explicity well-designed, that it will be somewhere between poorly-designed and pathologically designed.

And, it's rather hard to design such a system without substantial interaction with and feedback from the entire contemplated user community.

The odds that an off-the-shelf system can be simply dropped into an unprepared hospital setting and "take" are low, regardless how strongly this is desired or mandated from above, or promised by the vendor. In fact, there may be an inverse relationship between how much the system is seen as imposed from above ("take it or leave") and social acceptance of the corresonding cultural change that is required to readjust to that technology. As Public Health has learned repeatedly, outside interventions that are not culturally-sensitive, dropped from a speeding helicopter in local villages, tend to be barely tolerated with false smiles during implementation, then die a rapid death as soon as the implementation team leaves.

We'll have a sense that this concept is finally understood when we see EMR development teams start with the idea of social acceptance of this new paradigm (electronic collaboration), and when the planning team includes social psychologists, cultural anthropologists, and people from the Information Sciences. If the problem is perceived as simply "electronic records", that is, as one related to databases and messaging tasks, and human beings interacting are not prominantely featured on any of the architecture diagrams, then the odds are against success of the project. There will be large-scale social "tissue rejection" of the kind that Public Health has encountered routinely so much for decades, in response to which Public Health has developed the ecological model, "PRECEDE/PROCEED", etc. (See Health Program Planning - An Educational and Ecological Approach ed., by Lawrence W. Green and Marshall W. , 4thKreuter, McGraw-Hill, (c) 2005 - 1st ed (c) 1961.)

So, it's not that the solution to such problems are unknown - they are just not part of the "Information Technolgy" literature, but are instead over in the "Public Health" literature, and the two have very little cross-talk. This is where there is a pressing need for Public Heath Informatics to step in and take a lead getting these disparate groups to talk to each other.

Later I'll also recommend that Public Health Informatics may be required to cross the bridge between the "feedback control problem" that public health keeps crashing into, and the "feedback control solutions" that Control System Engineering has mastered, off in a different universe that again has no cross-talk in the literature.