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 NACHC FOM/IT

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 country’s economy) NACHC FOM/IT

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) NACHC FOM/IT

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 NACHC FOM/IT

5. The Question Really Is… • How can technology such as software & hardware systems be more successfully adopted by healthcare organizations? NACHC FOM/IT

6. & The Answer is… • Co-evolution, but we’ll 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 NACHC FOM/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 NACHC FOM/IT

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.) NACHC FOM/IT

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 NACHC FOM/IT

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) NACHC FOM/IT

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 NACHC FOM/IT

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 NACHC FOM/IT

13. Where Has It Worked? • Two examples (that I’ve 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 R&D & Marketing/Sales groups • Development team interacted with these teams over 6 months to modify product NACHC FOM/IT

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 NACHC FOM/IT

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 NACHC FOM/IT

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 R&D group during the course of this process as the product evolved NACHC FOM/IT

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 can’t 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. Don’t be afraid to take some of these opportunities as this will create even closer alignment of the technology & your organization NACHC FOM/IT

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 NACHC FOM/IT

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 NACHC FOM/IT

20. remember – entropy requires no maintenance NACHC FOM/IT

21. Questions? David Hartzband, D.Sc. dhartzband@rchnfoundation.org dhartz@mit.edu 617-501-4611 (mobile) NACHC FOM/IT