Linearity of Expectation (LoE)

Introducing "Digital Health Evidence"

noreply@blogger.com (James BonTempo) — Mon, 01 Jun 2020 23:41:00 +0000

Several years ago I worked with the K4Health team to build mHealth Evidence. When the K4Health project ended, the platform was no longer actively maintained. Also, in the intervening years, the focus of our field has expanded beyond mHealth to the much broader Digital Health.

These two things inspired me to spend the last few days building a new site: Digital Health Evidence.

Much like its predecessor, Digital Health Evidence is built on top of PubMed, but narrows its collection down to articles relevant to Digital Health. It also provides a few "Quick Searches" that make it easy to retrieve evidence on key topics; for example, MNCH, CHWs, Decision-making, Privacy & Security, AI, and several others. And of course, users can write their own queries to retrieve whatever evidence is most relevant to them.

If you want to check it out, feel free to visit http://www.digitalhealthevidence.net/. And if you have any thoughts about how to make Digital Health Evidence even better, please feel free to share them!

P.S. If you're a developer and are interested in contributing to the code base, you can find Digital Health Evidence on GitHub.

The purpose of #ICT4D in one diagram

noreply@blogger.com (James BonTempo) — Mon, 23 Feb 2015 04:05:00 +0000

The purpose of ICT for development is quite simple, really. It can be captured in one basic diagram:

The most obvious consequence of this understanding of ICT4D is that if your initiative isn't increasing effectiveness or efficiency (or both) then you shouldn't be doing it.

It can also help make sure, for example, that when faced w/research results that don't demonstrate any (additional) impact you don't forget to ask, "Well, did it cost less?" Because if the impact was the same as the standard approach but it cost less then that's an important result (i.e., effectiveness is not the only measure of success in ICT4D). I regularly see missed opportunities to show cost savings in situations where (additional) effectiveness isn't successfully demonstrated.

What is also perhaps less obvious is an indication of why ICT4D is often equated w/innovation. I've heard folks refer to innovation as a way of doing something "better, faster, cheaper." The first (better) is effectiveness, the other two (faster, cheaper) are efficiency. Hence, given the purpose of ICT4D is to increase effectiveness &/or efficiency, it is by definition innovation.

But what do you think, does this one diagram pretty much sum up the purpose of ICT4D?

P.S. While the diagram shows a linear relationship between resources & impact---more resources, more impact---I'm not suggesting that's necessarily the case. I'm using a simplified graph to demonstrate my point.

Hype curve, meet diffusion of innovations, Part II

noreply@blogger.com (James BonTempo) — Sat, 04 Oct 2014 17:36:00 +0000

In the first part of this thread, "Hype curve, meet diffusion of innovations," I simply threw up an image that overlaid Rogers's Diffusion of Innovations curve on top of Gartner's Hype Curve without much else---simply a question: "Notice anything interesting?"

Well, here's what I noticed immediately, at least:

The point at which the innovation starts to climb out of the "Trough of Disillusionment" is the point at which the Early Majority starts to adopt it.
The period during which the innovation is climbing up the "Slope of Enlightenment" is the period during which the rate of adoption, or "Market Share %," is the highest.
The point at which the innovation reaches the "Plateau of Productivity"is the point at which the Late Majority begins to adopt it.
The period at the end of the "Plateau of Productivity" where the Hype Curve flattens out is the same period during which the Laggards adopt it and the "Market Share %" flattens out.

In some sense, this is all intuitive:

As the benefits of an innovation begin to be realized, it starts to become attractive to those beyond the early adopters.
As the rate at which those benefits are realized increases, and the rate at which additional benefits are discovered and realized increases, the rate at which the innovation is adopted increases.
When the full range of benefits of an innovation have been discovered, and it's clear that they are realizable, those who were more skeptical begin to adopt it.
As an innovation settles into maturity, and is no longer in any way controversial, even the strongest hold-outs are won over (or those who were never going to adopt it still don't and won't).

Again, all of this seems pretty intuitive and matches pretty well with experience, so this isn't exactly rocket science. But what surprised me was how all of this in some sense simply "fell out" of an image that I just threw together by combining two completely unrelated images I pulled from very different corners of the Interwebs and resized so they were the same dimensions. Coincidence? Maybe not.

By the way, Dave Algoso makes some great---and hilarious---additions to the Hype Curve in his "Hype cycle for development ideas: 2014 edition." Check it out!

Hype curve, meet diffusion of innovations

noreply@blogger.com (James BonTempo) — Mon, 02 Jun 2014 17:22:00 +0000

I've been thinking a lot about the adoption of ICT here @ CCP. I'm lucky that, in my current role, it's an appropriate way to spend (some of) my time :)

Two things that came to mind this morning while thinking about this were the Gartner Hype Curve & Rogers's Diffusion of Innovations. Just for the heck of it, on a bit of a whim, I decided to juxtapose the two curves to see how they lined up. See the result below...

I didn't modify the curves at all except to make them the same relative size and a bit larger. Notice anything interesting?

Image Credits:
Gartner Research's Hype Cycle diagram by Jeremy Kemp.
The diffusion of innovations according to Rogers (1962) by Everett Rogers.

The slow death of ICT4D, Part II

noreply@blogger.com (James BonTempo) — Sun, 30 Mar 2014 15:43:00 +0000

In my previous post, The slow death of ICT4D, I put together an admittedly rushed timeline (using knight labs' awesome TimelineJS tool) that captured some of what I thought were waypoints along a declining trajectory of the field of ICT4D. Several folks misunderstood my post to be a re-hash of a previous debate regarding the definition of the term. It wasn't.

Mike Trucano, Ken Banks, Matt Berg and Srinivas Yerramsetti were more or less with me. But others were not, including Wayan Vota and Tony Roberts (who wrote a thoughtful riposte, "Death of ICT4D 'Greatly Exaggerated'"). And Joel Selanikio and Steve Song fell into what was basically a "Who cares?" group.

But it was the ICT4D man himself, Richard Heeks—who I actually quoted in my timeline, and of whom I'm a big fan—that called me out in a comment to Tony's post. He said that behind my link-bait of a title there wasn't enough specificity or evidence. And you know what? He's right. Hence, this follow-up post.

First, let me draw what, in my mind at least, is a distinction between the study of ICT4D and its practice. The former takes place in the ivory tower of academia (and what a comfy tower it is!) and tends to be concerned with big-picture things like the relationship between ICTs and socioeconomic development: What is the effect on GDP if we add 10 more phones for every 100 people? How does the ubiquity of ICTs affect power dynamics and democracy? And other such lofty (and important) questions.

The practice of ICT4D is a different beast altogether. It is the domain of international NGOs—and their donors—engaged in the deliberate activity of international development; i.e., working overseas and "in the field," not their own backyard (this is where I come into closest alignment with Erik Hersman's "Subtle Condescension of ICT4D"), on development projects in health, education, agriculture and other sectors. This is where the perfect theories of ICT4D run into the real, messy world. In some sense, it's where a transition occurs from ICT and D to ICT within D. (That's not a perfect distinction, but I'm going to keep it for now.)

It's in the field of ICT4D practice, its implementation within international NGOs, where I see major changes ahead, where the "slow death" is occurring. And it has everything to do with Jon Camfield's observation:

@jamesbt @wayan_vota @whiteafrican @kiwanja did #ICT4D jump the shark, or become embedded & expected in "normal" int'l dev?
— jon camfield (@joncamfield) March 16, 2014

When ICT becomes mainstreamed within international development, when it becomes "expected," it will no longer be special and it will cease to be the domain of a select few with specialized skills (i.e., many of us who currently call ourselves ICT4D practitioners). Personally, I'm already witnessing this: half of my ICT team has never written a line of code, built a computer from its individual hardware components, or used a crimper and made ethernet cables. They're not technologists, they're public health professionals with a particular interest in or affinity for technology.

But the reality is they don't need to be technologists. With the continued strengthening of local ICT ecosystems (e.g., see this map of technology and innovation hubs in Africa), the technical capacity will increasingly be supplied by local partners. In fact, 10 years ago, when I was involved in my first ICT4D project in Mozambique, the actual development of the system was done by a local firm and almost every project I've been involved in since then has followed the same model. And as the tools themselves continue to get easier to implement, requiring nothing more than simple configuration (think: Magpi or TextIt), there will be even less need for ICT4D specialists. Those working on ICT projects in international development organizations don't need to be technologists, they simply need to understand the processes of, and approaches to, implementing ICT projects so they can effectively work with technology partners. Or they may only need to know how to use a browser-based GUI and install and configure a mobile application.

In my corner of the international development world, global health, we will know the final blow to ICT4D (or at least its ICT for Health incarnation) will have been dealt when ICT becomes a part of the Public Health core curriculum—certificate programs are already cropping up, like this one in Public Health Informatics at Hopkins—and when newly graduated MPH students are just as comfortable working with a (local) software development firm (or simply using a web-based tool) to develop an mHealth intervention as they already are working with community organizations to implement traditional health promotion campaigns. At that point, which is on the horizon and rapidly approaching, there will be no need for ICT4D staff—everyone will have the (minimal) requisite skills and implementing ICT projects will be a part of everyone's job. And that's when I'll be out of mine.

The slow death of ICT4D

noreply@blogger.com (James BonTempo) — Sun, 16 Mar 2014 15:28:00 +0000

UPDATE: Let me be clear, this post is not about arguing over the meaning of the term "ICT4D." Like the INGOs that are its vehicle, ICT4D's days are numbered. With this timeline I am attempting to lay out some of the waypoints along the trajectory of the slow death of ICT4D as a field. It's time we started looking for new jobs...

Some thoughts on scale & complexity in #ICT4D

noreply@blogger.com (James BonTempo) — Sun, 01 Dec 2013 17:57:00 +0000

Some assumptions:

Going to scale requires significant investments in systems & infrastructure
Investors (esp. risk-averse government donors) require proof of efficacy before making large investments
Proof of efficacy is established in small, highly-controlled environments
Development (health, education, agriculture, etc.) is complex: i.e., a complex system
In complex systems, properties emerge that can't be predicted/don't follow the dynamics at lower (i.e., smaller) levels of scale

Some related challenges:

How can we be confident our ICT4D interventions will scale (easily) given we can't predict what unforeseen land mines might await us as they do?
Given that, how can we convince investors (& ourselves) that their investments (esp. the up-front ones) are warranted?

These are just some things I've been thinking about lately. I'd be curious to hear your thoughts on them...

mHealth Reality Booth (#131)

noreply@blogger.com (James BonTempo) — Fri, 02 Dec 2011 19:14:00 +0000

Some of the top organizations and corporations working in the mobile technology and health space will gather December 5–7 at the mHealth Summit near Washington, D.C. The summit program offers several tracks and a wide range of sessions and exhibits for just about anyone interested in mobile technology and health.

A few months back, Linda Raftree and I came up with the idea to co-host a “Reality Booth” at the Summit.

Innovative business models are great. New behavior change communication technologies open huge opportunities. Mobile tools to help health professionals build capacity to improve healthcare systems sound like a dream come true. But what happens during implementation? What are the real life barriers and challenges that practitioners face when implementing programs with an mHealth component? Where can you get some honest answers?

The Reality Booth is a place for practitioners working in rural settings or implementing programs in ‘developing’ countries to connect with others working in similar situations and facing comparable challenges. It offers a space to share and learn from peers who implement mHealth programs on the ground and to get advice on resolving the kinds of difficulties that probably won’t be highlighted during the official presentations.

We’ve invited some of the most respected mHealth practitioners to attend the booth for an hour or 2, and are pleased to mention that we’ll have some fantastic folks joining us. (We’re filling our last few remaining slots, so stop by booth number 131 for the full schedule on Monday!)

Come and share your mHealth reality stories, ask your implementation questions and get some practical or strategic advice from:

Monday, Dec 5
11:15-12:00 Isaac Holeman
12:00-1:00 Heather La Garde
1:00-2:00 David Isaak
2:00-3:15 David Cantor
4:30-5:30 Pamela Riley

Tuesday, Dec 6
2:00-3:30 David Cantor
3:30-5:00 Neal Lesh

Wednesday, Dec 7
10:00-11:00 David Isaak

We’re also planning to make a short video on ‘mHealth Realities,’ so stop on by if you have a ‘reality story’ to share.

The Reality Booth is co-hosted by MCHIP, USAID’s flagship maternal, newborn and child health program, and Plan International USA, one of the oldest and largest children’s development organizations in the world, and co-coordinated by James BonTempo of Jhpiego and Linda Raftree of Plan International USA. Contact James (JBonTempo@jhpiego.net) or Linda (Linda.Raftree@planusa.org) for more information.

In addition to the Reality Booth, we’re hosting ICT4Drinks at Thai Pavilion from 5.30-7.30 on Tuesday, December 6. Meet and mingle with your fellow mHealth practitioners! Free drinks for the first folks in the door and fantastic Thai munchies for everyone!

Provider-level supply side elements of doing

noreply@blogger.com (James BonTempo) — Sun, 17 Apr 2011 15:12:00 +0000

My wife likes to make fun of me for having a whiteboard in my "man cave." She thinks I'm a total nerd. And I am. Anyway, while trying to free up space--rearranging and rewriting some things, including a diagram re: instructional design as user experience design--I found myself inspired to draw this "elements of doing" diagram:

Six provider-level supply side elements of doing

I've considered similar things before (e.g., see Clinical decision-making, a behavioral economics perspective) but this is a little different because it goes beyond making a decision to actually doing (i.e., putting that decision into practice). The six elements I came up with--and there are probably more I haven't thought of--are: capacity, motivation, tools & materials, time, rights, demand.

I was going to provide more detail about each element but, as I started to write everything out, it seemed unnecessary: they all seem pretty self-explanatory to me (but be sure to let me know if they're not).

I'm sure this is nothing new; my ignorance of writing, academic or otherwise, on this subject making me think it's somehow unique. If you can point me to any existing articles, essays, books, etc., please do!

What I Didn't Know Yesterday #62: Why mLearning & ICT4E in general is hard

noreply@blogger.com (James BonTempo) — Thu, 10 Mar 2011 04:19:00 +0000

MobileActive has written a piece about mLearning and how it hasn't seemed to live up to it's potential (hype?). As I thought about this a thought occurred to me: learning isn't transactional and that may have something to do with it.

Take mBanking -- it's pretty simple. Money goes in, money gets transferred, money gets withdrawn. Easy. Or even healthcare. Steps in a protocol are followed, data is collected, diagnoses are determined, treatments are administered, you wait to see how the patient responds, then repeat. There are a wide set of possibilities but, still, it's a pretty straightforward process.

Health service provision is really just pattern recognition -- recognizing symptoms and treating them appropriately (maybe my father-in-law, a philosophy professor and playwright, is on to something when he says an M.D. is just a glorified professional degree :P). And banking is just storing and transferring information. Both things that ICTs are particularly well suited for.

But learning is anything but straightforward. It's certainly more than data collection, transmission or computation. And maybe that's why it's so difficult to find appropriate applications of ICT that will really effectively facilitate the process. I don't know, I'm just thinking out loud here...

What I Didn't Know Yesterday #66; Sometimes you know more than you realize

noreply@blogger.com (James BonTempo) — Thu, 10 Mar 2011 03:28:00 +0000

Sometimes you have more knowledge & expertise wrapped up in your head than you realize. And it simply takes the the right, probing questions to pull it out. I guess it's somehow related to my realization that teaching can potentially be more like facilitation (i.e., getting your learners to share their knowledge and effectively provide the necessary learning content by asking the right questions and guiding the conversation).

What I Didn't Know Yesterday #65: Everyone's looking to ICT

noreply@blogger.com (James BonTempo) — Tue, 08 Mar 2011 03:45:00 +0000

Today I attended a briefing at the World Bank on a report detailing what the future of health professions education around the world should look like. I was surprised to hear presenters make references to ICT, mobile technology and open educational resources. And not only that, one presenter actually called for the "aggressive use" of technology to support and transform education. I guess it's just nice to hear such respected non-techies make reference to the importance of and need for technology in the company of so many important decision makers. It makes me feel like my work is worthwhile. Now if only my colleagues were convinced of that, too...

What I Didn't Know Yesterday #61: Nintendo, it's like riding a bike

noreply@blogger.com (James BonTempo) — Mon, 07 Mar 2011 02:09:00 +0000

Today I joined some colleagues at Mr. Yogato. It's a frozen yogurt place near our office. But that's not the important part -- they have an old school (though 3rd generation) Nintendo set up there with a stack of games. Among them is Mike Tyson's Punch-Out. I popped that cartridge in and the next thing you know I was KO-ing Glass Joe & Von Kaiser like I was still 14 years old! Talk about muscle memory :P I'm going to have to go back and play when I have more time. But maybe next time I'll throw in Mega Man (also in that stack of games) instead...

What I Didn't Know Yesterday #63: Smalltimore

noreply@blogger.com (James BonTempo) — Mon, 07 Mar 2011 02:08:00 +0000

My friend Alan -- we went to college together almost (gasp!) 20 years ago and we haven't see each other in about 10 -- came to Baltimore for a party at his wife's friend's place. Her name is Ethel and she was a resident at University of Maryland. It turns out she knows a friend of ours, Eric, who is also a resident there. Then the twin sister of someone that I used to work with at Jhpiego showed up: her daughter was a clinical mentor for Ethel. And it turned out that two of the women that came with her live two blocks down the street from us. Sometimes the city can really start to feel like a small town.

What I Didn't Know Yesterday #64: Home improvement is never done

noreply@blogger.com (James BonTempo) — Mon, 07 Mar 2011 02:08:00 +0000

The problem with home improvement is that once you start doing it you realize there's a lot more that could be done. I started with fixing a crack in one of our plaster walls. Then I noticed there were these remnants of a baby gate from the previous owner that I wanted to remove (which required more plaster work). Then while painting over the fixed plaster I noticed the banister could use some paint. Then I noticed there was a small hole in the wall in the kitchen that needed to be filled (and then painted). Then...

What I Didn't Know Yesterday #60: Not every opportunity can/should be taken

noreply@blogger.com (James BonTempo) — Fri, 04 Mar 2011 12:48:00 +0000

Today I was presented with a really interesting opportunity. Someone had actually sought me out with a decent offer, as opposed to the other way around (I'm usually the one approaching others with ideas). The unfortunate thing was that there was no way we could take advantage of this opportunity -- the timeframe was just too tight and our in-country staff already too overburdened to make room for more work.

It was one of those times when it becomes clear that not every opportunity can be seized. And I would add that even if an interesting opportunity can be accommodated for it doesn't automatically mean that it should be. As with all other business decisions, this sort of decision needs to be made in the context of many other things, not just time & staff availability -- most importantly, your vision, mission and organizational objectives.

What I Didn't Know Yesterday #60: Qualcomm

noreply@blogger.com (James BonTempo) — Thu, 03 Mar 2011 03:14:00 +0000

Today I attended Dr. Irwin Jacobs's (co-founder of Qualcomm) Blumenthal Lecture (and award ceremony) at Johns Hopkins University's Whiting School of Engineering. He shared with the group in attendance the story of Qualcomm's beginnings and how the team overcame adversity and skepticism to become one of the world's biggest and most successful technology companies. And I was particularly happy when he gave significant exposure to the Wireless Reach initiative -- a program to bring the power of mobile and wireless technologies to aid underserved communities around the world. Perhaps someday I'll be lucky enough to work with the team at Qualcomm to apply the power of ICTs to some of the most pressing development issues...

What I Didn't Know Yesterday #59: Is mobile penetration higher than we think?

noreply@blogger.com (James BonTempo) — Tue, 01 Mar 2011 20:15:00 +0000

In the article, Are Mobile Phone Penetration Rates in Sub-Saharan Africa Really As Low As They Seem?, Russell Southwood makes the case that mobile penetration among adults in sub-Saharan Africa (SSA) may actually be incredibly high. Here's why...

Current penetration rates are calculated as a percentage of the total population but in many SSA countries those under 15 make up a sizable portion of the population. Recalculating mobile penetration against the percentage of the population over 15 (i.e., the "addressable market") can change the figures dramatically. For example, in Liberia, in 2009, the mobile penetration rate calculated as a percentage of the total population was 31% but a recalculation based on the proportion of the population over 15 pushed the number to 60% -- almost twice as high as originally thought.

So, what's the relevance to ICT4D? Chances are mobile ownership and access in many countries -- even outside of SSA -- is even higher than we think, especially among adult target populations, making mHealth and mLearning interventions even more feasible and desirable.

What I Didn't Know Yesterday #58: Categorizing the computer nerds

noreply@blogger.com (James BonTempo) — Mon, 28 Feb 2011 23:10:00 +0000

Some time ago I stumbled across the ACM's Computing Curricula 2005: The Overview Report, but I hadn't gotten around to reading through it. Well, I finally had a chance to check it out today and it was actually really helpful. It gives a rather clear description of the difference between undergraduate programs in computer engineering, computer science, information systems, information technology, and software engineering. And it describes them both in terms of content covered in a program as well as the competencies students will develop.

I didn't study any sort of computing as an undergraduate -- I have a BS in Biology -- but I did my graduate MS work in computational linguistics. And I have over 15 years of practical experience in ICT across various fields. Applying the criteria from the report, I'd say I'm equal parts software engineer and information systems person, with a little bit of computer science (from graduate school) and information technology (from a few years doing technical support) thrown in for good measure :)

What I Didn't Know Yesterday #57: The craft fair is cool

noreply@blogger.com (James BonTempo) — Sun, 27 Feb 2011 07:14:00 +0000

The craft fair in Baltimore is pretty cool. Alex and I went down there to see some friends of her family that had a booth there. Their work (silk scarves) was great and there was a lot of interesting stuff there. It may have even been worth the $14 per person :P

What I Didn't Know Yesterday #56: Give up, move on

noreply@blogger.com (James BonTempo) — Sun, 27 Feb 2011 07:11:00 +0000

I still don't think I've learned when to give up an idea. I often argue a position, sometimes with really good evidence, but afterward I realize it wasn't worth the effort. If people are that dead-set against you from the start, maybe it's not worth the fight. Maybe you should just move on. Somebody else will probably take you up on it...

What I Didn't Know Yesterday #55: Everett Rogers, meet Kentaro Toyama

noreply@blogger.com (James BonTempo) — Fri, 25 Feb 2011 05:45:00 +0000

[BTW, I use the "!" convention from coding to mean "not." So, for example, "!capacity" means "without or lacking capacity." Sorry, once a coder always a coder :) In the whiteboard image below I use the negation symbol from mathematical logic that I don't have access to on my iPhone keyboard.]

While talking with a colleague about behavior change (a topic I find thoroughly fascinating) I realized he was drifting dangerously close to Toyama-esque "capacity and intent" territory. And as we chatted I found myself drawing a two-by-two square with capacity and !capacity down the side and intent and !intent across the top.

What we realized is that the initial behavior change will be realized in the upper-left quadrant were capacity and intent exist. Then I asked, "What's easier, developing capacity or intent?," to which my co-worker said "developing capacity." So, we decided that change would occur next in the lower-left quadrant where intent existed but capacity did not. After that comes the upper-right quadrant where capacity exists but intent does not. And, finally, the lower-right quadrant where neither capacity nor intent are present.

But, while this work with the quadrants was happening I was also drawing another picture -- Everett Rogers' diffusion of innovations curve. I couldn't help myself and suddenly realized the link between Toyama and Everett...

Capacity and intent = innovators and early adopters.
!Capacity but intent = early majority.
Capacity but !intent = late majority.
!Capacity and !intent = laggards.

What do you think, can we map Toyama's "capacity and intent" ideas to Everett Rogers' diffusion of innovations in the way I've done here?

What I Didn't Know Yesterday #54: Need != desire

noreply@blogger.com (James BonTempo) — Thu, 24 Feb 2011 23:22:00 +0000

I was at a meeting this morning and people were talking about designing mHealth interventions that met a known need. But I felt compelled to speak up and add that while needs are important, so are desires. In fact, I'm not sure which one is more powerful and has more of an effect on the potential success of a project. All I do know is that the two are not the same, and when they're not aligned you can run into significant implementation challenges.

What I Didn't Know Yesterday #53: Watson to tackle healthcare

noreply@blogger.com (James BonTempo) — Wed, 23 Feb 2011 04:48:00 +0000

I guess now that IBM's Watson AI has won Jeopardy it's time to put the technology to better use. The next frontier? Healthcare and clinical decision-making. I guess it makes sense seeing as most clinical diagnoses are actually the result of pattern recognition and data mining. Now, if they could compress the same system so that it would fit on a phone -- maybe an Android device -- that would be awesome. I imagine it's only a matter of time...

What I Didn't Know Yesterday #52: A recipe for eHealth success

noreply@blogger.com (James BonTempo) — Tue, 22 Feb 2011 04:23:00 +0000

To those of us who have been working in systems development for a long time none of this really comes as too much of a shock -- we've always known it intuitively. But it can be rather useful when someone puts a structured framework around one's implicit approaches. That's what I found today in an article about the barriers to implementing eHealth initiatives. The four major categories of stumbling blocks based on the normalization process theory used in the analysis: disruptions to provider-client interactions (existing work flows), challenges to relationships between groups and cadres (established roles and responsibilities, hierarchies), incongruence with skill set (technological capacity), and divergence with organizational goals, leadership and resources (operating environment). I think at one time or another I've run into all of these -- sometimes more than one at the same time! You'd do well to keep your eye out for them and do your best to plan ahead for their eventuality...