New Approaches to Technology Adoption for Healthcare Organizations

1
New Approaches to Technology Adoptionfor
Healthcare Organizations

• David Hartzband, D.Sc.
• Director of Technology Research
• RCHN Community Health Foundation,
• Research Scholar, Engineering Systems Division
• Massachusetts Institute of Technology

2
We all know that.

• Close to 20 of the GDP of the U.S. will be spent
  on healthcare this year
• Within 10 years, this figure will be equal to the
  total spent in the U.S. on all goods
  services today (50 of the GDP)
• This rate of increase is not sustainable by our
  economy (or any other countrys economy)

3
We Also Know That

• Health Information Technology (HIT) is predicted
  to be one of the major factors in controlling
  healthcare costs improving productivity
  outcomes
• RAND predicts 10s of billions saved from the
  adoption EHR technology 100s of billions saved
  if healthcare could be as efficient in its use of
  technology as other U.S. industries (aerospace,
  auto)

4
I Previously Reported

• My research at MIT has shown that such cost
  savings productivity improvements can not be
  realized unless new technologies are not only
  acquired (i.e. purchased) but also adopted
  effectively used.
• Even when systems such as Practice Management,
  EHR, etc. are bought, they are most often
  ineffectively deployed utilized

5
The Question Really Is

• How can technology such as software hardware
  systems be more successfully adopted by
  healthcare organizations?

6
The Answer is

• Co-evolution, but well get to that
• My previous work has also shown that technology
  is much more likely to be adopted if it is
• Well aligned with the cultural environment work
  processes of the people in your organization who
  actually do the work it is supposed to facilitate
• The technology should fit the actual work (be
  useful in real ways) potentially allow people
  to do things that were difficult or not possible
  to do without it

7
This Gets Us to Barriers

• Four types of barriers to adoption
• Technical
• System complexity lack of interoperability,
• Social Cultural
• Unprepared workforce, training knowledge issues
• Privacy confidentiality issues
• Cost
• Initial investment cost
• Lack of funding for ongoing expenses (upgrade,
  maintenance, etc.)
• Unclear return on investment
• Alignment
• System not well matched to workflows work
  styles of users
• System not useful to users

8
Collaboration Breaks Through Barriers

• Co-evolution is a collaboration between the
  organization(s) the people actually using the
  technology the organization(s) people
  developing it
• Some time ago, I did a study with colleagues at
  Stanford that tried to determine what criteria
  organizations needed to meet in order to
  collaborate with each other. These included
• Shared goals
• Similar asset skill availability
• Similar reward structures
• In other words, organizations must actually be
  peers, otherwise a relationship other than
  collaboration is established (parent/child,
  teacher/student etc.)

9
Co-evolution?

• Current research indicates that this might be an
  answer to more effective technology adoption
• Co-evolution is the idea that in order to
  actually be aligned with the work done in an
  organization, the technology has to be evolved
  (or modified) by a process of iterative
  improvement while it is being used in an
  organization
• It is co-evolution because the organization is
  often changed during this process as well

10
How Is Technology Developed?

• In most cases, software ( hardware devices) are
  developed by engineers technology designers who
  are not experts in whatever work the technology
  is aimed at facilitating
• In the last 10 or so years, it has become
  fashionable to include human factors
  usability experts in these design teams
• This often results in technology that is
  technically usable, but not useful this is an
  important distinction
• In some recent cases anthropologists have been
  used to try to align with the cultural aspects of
  work ( in a very few cases of specific
  organizations, more later)
• The extent to which this has been successful is
  debatable
• Current dogma centers around users developing
  their own applications (mainly on the web)

11
How Does Co-Evolution Work?

• A finished product (not a Beta or test version)
  is deployed into an organization
• The development team commits to a regular
  schedule of interaction with the people actually
  using the product (not a management team)
• The development team discusses modifications that
  are suggested by the experience of using the
  product with the work team, makes decisions on
  product evolution makes changes in a rapid
  development mode so that the modified product can
  be deployed back to the work team
• This is iterated until both teams are (mostly)
  satisfied
• In the course of this interaction, the
  organization often changes in relation to the
  technology

12
What Does This Really Mean?

• The developer organization designs implements a
  product that is highly configurable (as opposed
  to customizable), this team includes people who
  have actually done the work they are trying to
  facilitate
• The idea is to change the code only as a last
  resort
• The developer organization the user
  organization collaborate with each other over a
  period of time while the product is being used in
  production
• The developer organization the user
  organization configure the product to align more
  closely with the workflows workstyles of the
  users
• These iterations continue as quickly as feasible
  with respect to testing quality assurance
  practices until both organizations agree that the
  goals of the collaboration have been met

13
Where Has It Worked?

• Two examples (that Ive been involved with)
• General Motors C4 Program a very complex
  paperless design system was deployed to about 15
  GM design manufacturing groups (1999-2002)
• The technology development team interacted with
  the GM groups over about 12 months to modify the
  system as it was used
• Program also included an anthropological study,
  results were used to structure the interaction
  modify the product
• Small drug discovery company (Cambridge, MA)
  (2006)
• Very complex process modeling management
  software deployed into RD Marketing/Sales
  groups
• Development team interacted with these teams over
  6 months to modify product

14
GM Details

• Very complex quasi-collaboration between GM C4
  car company, Digital Equipment IBM to develop
  a complete paperless design system (requirements
  definition, CAD/CAM, design notebook,
  engineering-manufacturing translation, BOMs),
  1.5B budget
• Only part of the system ever delivered
• Anthropological study used to guide tech
  development adoption work
• Development teams worked sequentially in
  design/development, review, use cycle
• Organizations (GM vendors) siloed culturally
  technically (DEC dev on VMS, IBM on Unix) so very
  little real collaboration acheived
• Mosaic adoption by organization function
• Parts of the system used for several car programs
  until 2004

15
Drug Company Details

• Not exactly GM, 200 people in company, 120 Ph.D.
  level scientists
• Development work was primarily process model
  development integration of several existing
  products (that the company was already using) to
  provide a new approach (workflows) to automated
  support for early stages of drug discovery
• Collaboration between scientific teams (3 teams,
  17 total people) 2 developers (DJH 1
  programmer)
• Iteration over about 6 months produced an
  integrated product suite with a single database
  visual UI that closely matched to workflows
  designed by the combined team

16
What Happened?

• The GM product was never fully deployed. Cultural
  inertia was a large part of why, but the product
  set was judged to be a better fit than anything
  they had previously used (including several
  products developed by the GM teams themselves)
• The drug discovery process manager is still in
  daily use. The company has several times looked
  at commercially available products, but stayed
  with the co-evolved one because it matched what
  they did much better. The company actually
  redesigned their RD group during the course of
  this process as the product evolved

17
What Does It Mean For You?

• There are currently only a very few technology
  companies that work like this, but there are
  some look for them
• If you cant find one, talk with your current
  vendors to see how closely they can/will commit
  to this kind of process
• Your actual work process must be understood in
  order to have a target for alignment. Process
  documentation helps, but often you have to
  actually go through chart it as it actually is.
• Co-evolution will present opportunities to change
  both your work processes organizational
  structures. Dont be afraid to take some of these
  opportunities as this will create even closer
  alignment of the technology your organization

18
The Final Word (kinda)

• Technology can substantially improve operational
  effectiveness clinical outcomes, but only if it
  is actually adopted used by the people that do
  the work
• Technology will only be adopted used if it is
  well aligned with the work being done
• Co-evolution is one technique for allowing the
  technology to align with the work the people
  doing it. Part of the process may be that the
  work process organization change as they
  interact with the evolving technology

19
The Final Word for now

• There are many ways for CHCs to adopt new
  technology
• There is no magic bullet. Technology adoption is
  HARD work that must be done by the people who
  will use the technology
• There is no RIGHT way!
• Evolution, of any kind, is a dynamic process that
  modifies its participants as it progresses

20
remember entropy requires no maintenance
21

• Questions?
• David Hartzband, D.Sc.
• dhartzband_at_rchnfoundation.org
• dhartz_at_mit.edu
• 617-501-4611 (mobile)