Healthcare Information Technology: The Next 10 Years

   “Black holes, we all know, are these regions where if an object  falls in, it can't get out, but the puzzle that many struggled with over the decades is, what happens to the information that an object contains when it falls into a black hole. Is it simply lost?”

  Brian Greene, Professor of Physics & Co-Director, Institute for Strings, Cosmology & Astroparticle Physics, Columbia University


  (1)

In June of 2014, The Office of the National Coordinator for Healthcare Information Technology (ONC) published its 10-year vision for health information technology (HIT) in the U.S. (2)  Interoperability among HIT components was a primary & enabling aspect of this vision. Subsequently, they also published a roadmap for such interoperability that covered in some detail the technical, administrative & regulatory tasks & issues associated with achieving interoperability in the healthcare space. (3) I reviewed these proposals in several blog posts last year.(4) I was generally skeptical of what I saw as an effort that emphasized standards development & adherence as well as a certification process similar to the Meaningful Use process that I have not seen produce results other than software that is compliant with the test criteria, but not especially usable or useful for healthcare organizations (at least in my experience & opinion). In any case, it’s six months later & I wanted to review what was proposed, what I thought about it & where I think we’ll actually be in mid-2024 with respect to HIT & healthcare in general.
First, a review… The 10-year vision is described as follows in the ONC vision document:“An interoperable health IT ecosystem makes the right data available to the right people at the right time across products and organizations in a way that can be relied upon and meaningfully used by recipients. By 2024, individuals, care providers, communities, and researchers should have an array of interoperable health IT products and services that allow the health care system to continuously learn and advance the goal of improved health care. This “learning health system” should also enable lower health care costs, improved population health, truly empower consumers, and drive innovation. For example, all individuals, their families, and care providers should be able to send, receive, find, and use health information in a manner that is appropriate, secure, timely, and reliable. 
Individuals should be able to securely share electronic health information with care providers and make use of the information to support their own health and wellness through informed shared decision-making. An interoperable health IT ecosystem should support critical public health functions such as real-time disease surveillance and disaster response, and data aggregation for research and value-based payment that rewards higher quality care, not necessarily a higher quantity of care.” 
The salient points of this description are an HIT system that:

• Provides fully interoperable products & services
• Exhibits continuous learning such that the system is able to:
• provide higher quality care to individuals
• lower the cost of this care
• improve population health
• empower consumers
• Provide appropriate security & privacy for all functions
• Provide data aggregation for both research of various types & develop/use of value-based payment

My choice of the image & quote at the beginning of this article was deliberate. I do think that we are in danger of a trying to overachieve by dumping a huge amount of information & effort into what is essentially a black hole – OK, so maybe that’s an exaggeration, but not much of one.

The ONC’s vision is all about integration & learning systems. These are good foci, but does the vision actually mean to design & implement a system that enables integration? Or one that “learns”? So we have to define what we mean by integration (& then learning…), first integration. There are really two technically relevant terms here - integration & interoperability. The first has been the object of a huge amount of discussion, writing, prototyping & product development, while the second, & arguably the more important capability, has barely been mentioned. OK - it hasn’t been mentioned at all. This is another example of the scope of people working in healthcare who have not worked in other industries (just as healthcare isn’t a market, it also isn’t an industry, but that’s a topic for another day…). 

Some time ago , I wrote about the interrelationship of interoperability, integration & standards. As a software architect who has designed & led the implementation of a number relatively successful systems  & consulted on the development of many others, I have come to my own understanding of these terms as follows:

• Interoperability – the design criterion that allows independent software systems to share information, function & workflow with each other – This “ility” has to be designed in from the beginning (or a good deal of cost for redesign & reimplementation can be incurred).
• Integration – the work done to implement the interoperable design – When performed effectively, independent software systems can & do effectively share information, function & workflow at both user & system levels.
• Integration has often been seen as an after-the-fact issue. To this end, a whole category of systems has been developed – integration busses. These systems do point-to-point connection & usually proprietary translation & sharing of data, often through standards such as HL7 (at least in healthcare)
• Standards – the set of guidelines for the design & implementation of a (software) system so that some specific purpose, such as informational interoperability, can be realized.

My current view is that a substantial amount of attention has been paid to integration & standards in the ONC’s vision, but very little to actual interoperability. Standards are seen, in the vision, as the mechanism for providing integration of data. What does this actually mean? & Why is it important? As long as I have been developing software, I have been involved in standards efforts . Even the most successful of these, for instance the development of the V1 SQL standard in 1986, was marred by considerable acrimony & noncompliance which resulted in a flawed (IMHO) standard that because it was so useful was able to both enable substantial improvements in query efficiency & effectiveness for relational databases even as it cemented the differences among “compliant” (& brand-based) implementations. My personal favorite questionable inclusion (that I opposed) in the SQL standard is the allowance of stored procedures which have been used both to very good effect & also made many query programs opaque & impossible to debug &/or interpret. Another favorite example, that I’ve written about before, occurred during the “debate” over CORBA interoperability when the representative from another company (Sun Microsystems) told me (I was representing Digital Equipment) that his definition of interoperability was that my system could send his system a properly structured request for information & his system could send mine a (properly structured) error message… “See, we’re interoperable”.

Personal anecdotes aside, the development of standards, like the development of software systems, is done by individual engineers & programmers who work for some entity (it could even be themselves) that has a vested (commercial &/or personal belief) interest & therefore an agenda that may or may not be aligned with creating the most effective & productive design for users. Even in open source development, an individual’s personal beliefs & biases are often imposed on a design to the detriment of its overall effectiveness (as witness what is happening in the Bitcoin community currently) . A good example of this of this is the work that was done on the SHIN-NY (State Healthcare Information Network – New York) architecture, developed by the New York eHealth Collaborative (NYeC), & intended to “enable widespread interoperability among disparate healthcare systems”  & to promote healthcare information exchange. The architecture was a multi-layer, integration bus dependent design that provided for connectivity, data modeling & storage, data exchange, interoperability orchestration & data integration. It was based on the functionality defined by ONC/HHS for the NHIN (later called NwHIN ) & depended on XML for data definition & transport (SOAP & WSDL) as well as the UDDI (universal Discovery & Description Interface) . At the time, I was acting as a consulting architect to the SHIN-NY committee. The committee was an issue in itself (over 30 members from hospitals, vendors, consultants, etc.), but that’s another story. The real issue (IMNSHO) was that the RHIOs (Bronx RHIO) & HIEs (BHIX, LIPIX, now both Healthix) & others had substantial grants from New York State & had already selected vendors to provide information management & exchange capabilities. Of course, all of these selections changed (many times) subsequently, but that is another issue & did not affect the point here,… which is that all of these vendors already had product & exchange architectures that were for the most part based on proprietary technologies that they considered their leverage (& which in all cases performed much better than the SHIN-NY prototypes). These vendors were not going to change their products or their deployments to match the design of the NYeC, especially since they had already been paid (with State money). The analogy with current ONC interoperability is, to me, striking & instructive. Current EHR systems have, almost exclusively, been designed as independent products. In fact, many EHR products do not “integrate” well (share data) with other offerings from the same vendor. Real work is needed to have such products share data in any meaningful or useful (choice of words deliberate…) way. This is despite the standards compliance claimed by many EHR products. At a minimum, C-CDA documents may be created, messaged to another system (often by the Direct protocol), & partially consumed or at least displayed by the second system. This would be fine if C-CDA provided an unambiguous data stream, but as John Loonsk (previously Director of Interoperability & Standards at the ONC & now at the Bloomberg School of Public Health, Johns Hopkins University) says: “…the C-CDA can be many things. It is almost infinitely extensible and the C-CDA support process does not have a history of providing strong constraints. As a direct result of the lack of a technical plan or architecture that targets the functional need, we now have numerous C-CDA variants, gigabyte-sized C-CDAs that providers rebel at receiving, at least five groups seeking to constrain C-CDA messages (will these be five new standards?), and we have few of the potential interoperability benefits. The C-CDA is not the target; it is a tool that if properly used could help get to it. A technical plan would clarify this relationship.”  Now we are looking at FHIR based on the REST protocol, but again, most vendors do not use FHIR, REST, JSON etc. & do not plan to convert their products anytime soon.
We haven’t even begun talking about functional & workflow interoperability. This is important because of the large number of data & information sources that healthcare organizations will need to access in order to be able to actually operate in the near-future care environment. As care transition becomes more & more important (& measured as part of pay-for-quality systems), the ability to share application function & user workflows across organizations will need to be addressed. eReferral is more than just sending a Direct message out into space (even if that space includes dual-endpoint identity verification). It requires the ability to seamlessly pass off data, functional capability & a shared workflow to the consultant & to receive it back. No systems (that I’m aware of) are currently planning for this, although it certainly should be part of a 10-year vision.
Let’s talk about learning for a minute. I wrote about the learning healthcare system back in 2014 . At that time, I discussed what a learning system might be, what work had been done historically & what types of systems already existed. In that piece, I wrote, “…learning can be thought of as “the ability to develop new knowledge & strategies for using that knowledge based on an understanding of current & previous results & information”. This ability is continuous & ongoing, the implication for a healthcare system is that whenever an actor (provider, patient, caregiver &c.) is using a part of the system, the system is moderating the user’s context (usage) & anticipates what information & analysis may be relevant. The system may then give the user the opportunity to request this information; which can be diagnosis, treatment suggestions, data on treatment, analysis of alternatives, public health implications, information & recommendations on amelioration of social determinants & many other possibilities.” This seems like a lot, so let’s break it down into what capabilities such a system would have to have:

• Ability to identify context (patient interaction, diagnosis process, provider request, patient request, research request etc.) & identify information & analysis relevant to this context
• Ability to access to substantial amounts of both healthcare & non-healthcare related data
• Ability to analyze & interpret this information in useful ways
• Use of statistical & BI type analyses
• Use of analytics for ultra-large data set analysis (structured & unstructured data)
• Formation of hypotheses & hypothesis testing
• Ability to make recommendations in multiple contexts (clinical, operational, financial,…) using these analyses
• A user experience level that works for multiple contexts & user types (providers, researchers, patients, caregivers, public health & policy workers, etc.)

Obviously, at least to me, we are not quite there yet with respect to this list of capabilities, but where are we? The closest HIT systems we have to this are the point-of-care recommendation systems being developed & evolved by several large healthcare organizations (Kaiser, Partners, Geisinger, Mayo,…). These systems analyze & look for patterns in conditions, treatment plans & outcomes in very large clinical data sets & make recommendations for diagnosis & treatment when an individual patient’s data is entered, usually at the point-of-care. Systems like “Dr. Watson” (IBM) also provide capabilities like this. The learning takes place as patterns are recognized & classified & these patterns are reused to make recommendations. Several of these systems, Watson is the best example, develop hypotheses based on data & related patterns & do hypothesis testing based on these intermediate constructs in order to determine a “best” set of recommendations. Eventually similar systems will be available (or the current systems will evolve onto commercial versions) that will allow healthcare providers to utilize the results of this learning for both research & treatment purposes. We are looking at 3-5 years (IMHO) before these systems are broadly available. There are, of course, other paths to learning in HIT systems, but this is the least resistance path I can see right now…
So the ONC vision concentrates on integration & learning for its 10-year roadmap. These are interesting & appropriate foci, but… I think there are much higher priority issues that must be addressed during this 10-year timeframe in order for HIT to evolve to be truly useful to all parties involved in healthcare relationships. What are these issues & where are we with respect to them? I thought you’d never ask:

• HIT systems, & especially EHR systems must be rethought, redesigned & reimplemented. EHR systems, as they currently exist, are designed primarily as billing, reimbursement & compliance measurement systems. They have very little to do with patient treatment, care transitions, preventive medicine & in particular they are not at all aligned with provider workflows. In addition they are difficult to navigate & do not facilitate best clinical practice… OK, tell us what you really think. I know that many vendors will speak endlessly about how their products do many or all of these things adequately, but talk to providers (note to ONC, CMS etc. – can’t we just say doctors, nurses & other healthcare professionals) who use them & you will hear a different story. I talk to docs & healthcare people all the time & I have yet had one tell me that their EHR facilitates the care model they use or is easy to use. Clinical information systems have to be designed so that they provide appropriate clinical function including such things as seamless information sharing, care transition, medication reconciliation, access to external clinical data, clinical decision support & facilitation of best practices – in short, they must be redesigned to do all of the clinical & sociocultural things that go into supporting the best patient care possible. Everything else, cost savings, quality & performance scoring, billing & reimbursement etc. are secondary priorities for the clinical systems. They are primary priorities for another set applications focused on these dimensions of healthcare. These applications might be interoperable clinical information systems, but it is impossible, at least in my experience, to design an application that has five first priorities & performs all of them at a high level.
• Each of these applications has to be designed & implemented for a specific user & role. User Interfaces of current EHR products are general & generally not suited for any one specific user category. UIs & workflows for billing & reimbursement applications should be different than clinical applications. Detailed work needs to be done to align the UIs & workflows of each application type with the needs & work processes of each user type.
• The current design of HIT systems is highly influenced by our current pay-for-procedure reimbursement system, Yes, I know this is changing… but, we have to accelerate this change & be serious about it. Current institutions cannot be allowed to maintain the status quo or we will not make progress on this. New payment models such as MIPS (Merit-Based Incentive Payment System  must be designed not as check-the-box quality measure systems or standards-compliance systems as these criteria tend to promote a race-to-the-bottom where everyone is meaningful use certified or PCMH compliant but few are meaningfully using HIT systems or actually providing care through a medical home model.
• What we know about patient health, patient care & outcomes is encoded in the EHR data. This data needs to be as accurate as possible in order for care provision & medical decision-making to be effective, but we know from many studies  that there are multiple types of errors reflected in EHR data. The redesign of HIT systems has to emphasize data quality & governance practices so that we can be confident in the accuracy of EHR & HIT data.
• Applications need not only to be interoperable, but need to be aware of classes of external data that may be important for the performance of strategic analysis. These applications will need to be able to acquire, store, manage & analyze very large amounts of heterogeneous data, including unstructured data such as text & image. Current HIT infrastructure is not adequate to provide these capabilities for both the large amounts of data that will be required & for the many different types of data that will also be necessary . In particular, the storage, maintenance & analysis capabilities provided by relational databases are already outdated. New types of infrastructure starting with ultra-large distributed file systems (Hadoop, Spark), associated analytic infrastructure (MapReduce, Yarn, Spark) & analysis facilities (Impala, Hive, R, Pig Latin etc.) are now required & will evolve over the next 3-5 years to be easier to use than current relational database & data warehousing facilities (this would not hard…). Healthcare organizations need to begin to make this transition now before their current infrastructure begins to fail.
• Healthcare applications also need to be smarter. This is where the ONC’s learning comes in. Machine learning as well as intelligent search, classification, pattern recognition & reasoning capabilities will need to become core parts of HIT systems to provide the kind of smart interaction with each user type that will facilitate improved care, better financial performance, provision of appropriate privacy & security & all of the performance areas we talk about with respect to HIT. Much of this capability is already under development or in prototype but, the right connections need to be made among designers, developers, users & other relevant parties so that these capabilities do get built into HIT systems.

The bottom line is that we have the possibility of creating a useful & effective HIT ecosystem by 2024, but in order to do so we need to stop emphasizing the recording & scoring of quality measures, meaningful use criteria, PCMH requirements etc. All of these measures are a part of how we think about healthcare information system, but they are not the core reason to develop & use them. If we keep emphasizing that the core reason for the development & use of these systems is the improve patient & population health, & we emphasize those things that are commensurate with that goal, we’ll have intelligent, interoperable systems that provide care with high measureable quality & low(er) cost without having to impose HIT systems designed to enforce policy requirements that do not always align with long-term care improvement. HIT systems will be designed & implemented by vendors over the next ten years to be in line with their commercial goals & a compliant with healthcare regulations as adherence to their first principle permits. If we do not want to continue the current chaotic ecosystem, we need to start now to deliberately move to a more care oriented design for HIT. Tomorrow, next week or next year is too late.

(1) The black hole at the center of our galaxy, Sagittarius A* (© NASA)
(2) https://www.healthit.gov/sites/default/files/ONC10yearInteroperabilityConceptPaper.pdf
(3) https://www.healthit.gov/sites/default/files/nationwide-interoperability-roadmap-draft-version-1.0.pdf
(4) http://posttechnical.blogspot.com/2014/07/the-onc-interoperability-vision-opinion.html (3 July 2015) & http://posttechnical.blogspot.com/2014/07/the-learning-healthcare-system.html (18 July 2015)
(5) The term “care providers” is broadly inclusive of the care continuum, reflecting primary care providers, specialists, nurses, pharmacists, physical therapists and other allied care providers, hospitals, mental health and substance abuse services, long- term and post-acute care facilities, home and community-based services, other support service providers, care managers, and other authorized individuals and institutions (original footnote)
(6) ONC vision document, pp. 2,3
(7) I understand that patients are consumers if you consider healthcare a true market, but I believe that using this language defocusses the actual goal(s) of healthcare. For my opinion on healthcare as a market, see: http://posttechnical.blogspot.com/2014/05/healthcare-as-market.html
(8) Interoperability, Integration & Standards or Why can’t I get the information I need when I need it? Financial Operations/Information Technology Conference, National Association of Community Health Centers, 10/2008.
(9) Rdb/VMS generated ~$1B total revenue over 10 years (bought by Oracle, 10/1994), DEC Objectbroker generated ~$600M revenue (bought by BEA, 1995?) both from Digital Equipment Corporation, Riverton HOW (500 customers in 6 months), & many others…
(10) ANSI X3H1 Committee, SQL standard V1, 1986; OMG, co-author of the CORBA Interoperability Standard, 1998 & many others...
(11) http://www.coindesk.com/hard-fork-developers-scaling-bitcoin/
(12) State Healthcare Information Network for New York (SHIN-NY) Technical Architecture Overview, V0.1 Draft, October 15, 2008
(13) https://www.healthit.gov/policy-researchers-implementers/nationwide-health-information-network-nwhin
(14) All W3C or Oasis standards at the time, now mostly superseded by REST protocol, JSON etc.
(15) Loonsk, J. 6 Reasons to Plan Architecture for Interoperability. GovernmentHealthIT. http://www.govhealthit.com/news/6-reasons-plan-architecture-ahead-interoperability, 24 September 2014.
(16) The Learning Healthcare System. PostTechnical Strategist. http://posttechnical.blogspot.com/2014/07/the-learning-healthcare-system.html. 18 July 2014.
(17) https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/Value-Based-Programs/MACRA-MIPS-and-APMs/MACRA-MIPS-and-APMs.html
(18) c.f. Improving Diagnosis in Healthcare, IOM; https://iom.nationalacademies.org/Reports/2015/Improving-Diagnosis-in-Healthcare.aspx;Deploying Analytics in the Healthcare Safety-Net, http://posttechnical.blogspot.com/2016/01/deployment-of-analytics-into-healthcare.html & references, Many others…
(19) Data as an Asset: The Evolution of Healthcare Information Technology. The PostTechnical Strategist. 9/2015. http://posttechnical.blogspot.com/2015/09/data-as-asset-evolution-of-healthcare.html

Design Thinking as Work Process & Strategy

 

Design is the method of putting form and content together. Design, just as art, has multiple definitions; there is no single definition. Design can be art. Design can be aesthetics. Design is so simple; that’s why it is so complicated.

Paul Rand[1]

[2]

I undertook a project in the spring of 1994. I had been thinking about the future of work, lot’s of people had including many people that I was interacting with at MIT. I started a series of discussions with Bill Mitchell[3], Tom Malone[4], Joel Moses[5] & Peter Rowe[6] that led me to begin thinking about a new model for knowledge work[7] (this is a lot of footnotes already, even for me…). The model I discussed with Bill Mitchell & others cast knowledge work more as a design process & less as an industrial (?) process. This seemed self-evident to me, even if it didn’t to some other people. What did I (& still do) mean by this?

Studies of the evolution of work[8] suggest that the future (knowledge) work paradigm will have several major characteristics: a) work will primarily consist of the identification, acquisition and manipulation of information and knowledge, b) the convergence of information and communication technologies will provide the basis for this work, & c) design process will provide the framework for both doing work as well as planning & strategizing about it. This knowledge work will be different than the work people now do, even current "knowledge work[9]". In order to determine what types of systems and devices need to be developed to facilitate this future knowledge work paradigm, we must first produce and validate, to the extent possible, a description of this work.

First, though, more on evolution. I believe that the next ten years will be partitioned into three broad categories of work evolution. These are shown in this table.

Current – now	Near-future – 3-5 years	Post-convergence 8-12 years
Mainly content based	Content & process based	Knowledge & model based
Focus is: problem solving	Convergence i.e. process & teaming	Design model, i.e. episodic, contradictive,…
Basis is: content-based deduction, individual contribution	Process innovation, group decision making, mixed & modal logics	Personal & group intuition, induction
Content driven	Group & technology driven	Intuition & interconnection driven

The categories can be described as follows:

• Content based (current)

o   Creation, management & use of content drives this phase

o   Work is mainly done by individuals & small (relatively isolated) teams

o   Focus is individual & small teams working to solve business problems

o   Feature needs revolve around integration of content management & collaboration with organization of projects/programs, budgets etc. also important

o   Technology is primarily program based, i.e. based on algorithms & deductive (formal) reasoning

o   Primary impediments & push-back focus on inadequate technology for collaboration (information & process) & inadequate organization for collaboration as well as strong commitment to co-location

o   Early adopters  have already moved on to the next phase

• Process based (3-5 years)

o   Deep integration of Content & Process drives this phase

o   Work is done by distributed teams

o   Focus is on collaborative problem solving in the work process context

o   Will require cross-organizational workflows

o   Process innovation & group decision making become important

o   Technology enables work process & collaboration, algorithms become less formal, more based on people’s work process

o   Advances made in both how people work with (“Big C”) content & collaboration as well as context-based problem solving enable a move to the next phase

o   Primary impediments & push-back focus on attribution for work & position of individual contribution

• Knowledge & model based (8-12 years)

o   Large-scale use of knowledge & models drive this phase

o   Work, i.e. what people do, takes on characteristics of the design work model

o   Work is done by a range of individuals, collaborative teams & collaborations among teams, location not an impediment

o   Focus is on knowledge & context-based problem solving to address business issues

o   Technology provides means of creating & maintaining context (organizational memory), large-scale knowledge modeling capability, problem solving assistance & ability to deal with very large-scale (Big C) content, use of ultra-large data sets for predictive analysis

o   Models of work & business problems create context for problem solving & business decision making

o   Primary impediments & push-back focus on intuition & contradiction based reasoning rather than standard deduction & induction

Before I move on to a description of a design work model, I’d like to focus on the impediments to this evolution for a minute. In the content-based phase, impediments to this evolution are mainly centered on the opinion that technology is inadequate to support the level of collaboration necessary. This is already inaccurate as technology today more than adequately supports most forms of collaboration. The more serious impediments, that are relevant to the next phase as well, are that organizational forms are not adequate to support collaboration & that a preference for individual contribution still exists in many organizational cultures. Many organizations, even those in technology companies, have not made the changes in composition &/or leadership needed to facilitate larger-scale collaboration that may have essential elements that are not co-located. These changes include:

• Distributed & decentralized management & decision making
• Formation of semi-autonomous to independent project & program teams
• Nonhierarchical communication structures
•  Nonhierarchical reward structures

Most organizations still adhere to either a push hierarchy (standard command & control structure) or a pull hierarchy[10]  (centralized management & decision-making with management pulling opinions, strategy & tactics from lower levels in the hierarchy), & these types of organizations have considerable difficulty in making the changes required for real collaboration.

In addition, there continues to be a bias towards individual contribution, especially in highly technical areas. The assumption is that a single person (or sometimes a single small group) is the only one with the knowledge or experience to create a design, architecture or program that will be effective & productive. The problem with this bias is that it is sometimes true &, at least in my experience, often much more productive than current egalitarian collaborative models.

Another issue that becomes more relevant in the process-based phase is that of attribution. Often group & individual reward structures, including the opportunity to continue to work on strategic & interesting problems, is tied to attribution. This is an issue if multiple groups can legitimately claim responsibility for the success of a project. Often the solution is to reward “everyone”. This can be less appropriate & much less appreciated by the people that actually affected the success of the project. There are organizational structures that may ameliorate this issue, but the cultural issues are harder to address.

Finally in the knowledge & model-based phase, the impediments are largely due to the real differences in how work is accomplished. People, except for some types of scientists & engineers, are not (yet) accommodated to working from models or from deep knowledge bases. In addition, during this phase, the decision-making norm will also be quite different – more biased towards guided intuition & non-deductive reasoning. The use of extremely large amounts of data for predictive analysis is also not yet well understood or accepted except in some specific & limited segments. It will take time for these norms, & for the design work model to take hold, therefore the 8-12 year timeframe.

There are a number of examples of knowledge work extant that provide a good start for the description of work & work process in the knowledge & model phase. I believe the best example of this is the general design process. Design is a knowledge-based component of much work, but in the future, most knowledge work will have the characteristics of design work. Rowe (1987), Norman (1990, 1992) and others have described design work that can be summarized as follows:

• episodic - context is preserved across a number of temporally distinct work periods during which different viewpoints or potential resolutions may be explored
• knowledge-based - deep and broad historical, technical and contextual knowledge is necessary
• eclectic – uses a wide range of problem solving techniques
• contradictions - fueled and/or motivated by the maintenance and resolution of tensions or contradictions including:
• ill defined/well defined task definition
• underconstrained/overconstrained
• intuitive/nonintuitive
• textual/nontextual
• "logical/nonlogical"
• theoretical/pragmatic
• content/context
• structure/function (organization/technology)
• time/completeness
• complexity/simplicity
• strategic/tactical.

The recognition, maintenance and resolution of these contradictions are the major characteristics of this new work paradigm. A contradiction occurs when some statement or fact is asserted to be both true and false. In the sense used here, a contradiction is a true work condition (s) or fact(s) whose assertion mutually excludes another true work condition or fact. The presence of unresolved contradictions creates tensions in the work. These tensions are present, to some extent, in our work today. The focus of our current work, however, is technical contents. This is true regardless of what the "technology" is that we are working with (VLSI, accounting practice, manufacturing process, etc.). Our near future work will be increasingly focused on process and teaming. Once the technical support exists to support diverse process and teaming models in real-time, this will become less of a focus. This should take 3-5 years for early adopters and perhaps as much as 10 years to come into general use. Future knowledge work (5-10 years out) will encompass these process and teaming models, but will more and more come to be structured by the tensions and contradictions listed above.

      What does it mean to say that knowledge work will be based on our ability to recognize, maintain and resolve contradictions and tensions? Recognition is defined as the awareness that something perceived has been perceived before. Maintenance is defined as the act of retaining or preserving some item or idea and resolution is the act of providing a solution to a problem[11] often through the resolution of one of the contradictions. These three processes applied to the list of tensions represent the essence of future knowledge work. This work will be characterized by: 1) the need to be aware that the tensions and contradictions in both the context and content of the work are necessary and that these contradictions provide the dynamic that drives the work, 2) that part of the work may require maintaining these contradictions and exploring the consequences of all potential possibilities, and 3) that eventually a solution or set of solutions must be derived from this tension.

      The formal presentation of the recognition, maintenance and resolution of logical contradiction helps us understand the role of these tensions in the description of a work paradigm. This formal presentation is outlined in Appendix A.

Let’s look at a near-future example of knowledge work in light of this work process description. Natalia is a 28-year old employee of a large public hospital. She has been tasked with determining the most prevalent disease comorbidities in the hospital’s patient population, determining the statistical characterization of the cost of treating those comorbidities & making recommendations for reducing the cost of that treatment. This is an issue in all healthcare organizations today that is only just at the edge of our ability to analyze & make anything other than anecdotal recommendations for. Here is a “design work process” description of this task:

• Episodic – This is not Natalia’s only work task, so she has to balance making progress on it with work on a set of other tasks. This means that she must take it up at intervals (in episodes) & that at the start of each episode, she must recover both the context & the content in the state that she left them & in a manner so that she can begin working on this task again with a minimum of redundant effort.
• Knowledge-based – Natalia will need a broad range of knowledge including: general medical knowledge, hospital clinical procedure, hospital financial procedure, operation of hospital clinical (electronic health record, practice management) software & financial management (cost accounting, billing) software, reporting software, analysis & business intelligence software, development, utilization & interpretation of financial models & other areas of knowledge just for this one task.
• Eclectic – Natalia will need to be able to access a variety of clinical & financial databases as well as create a financial model for determining revenue & cost associated with the prevalent comorbidities. She will need to be able to interpret the results of this modeling & translate those results (cost per comorbidity, revenue per comorbidity) into recommendations as well as be able to create a way to accurately & understandably present her results & recommendations.
• Structured & motivated by contradictions – Some of the contradictions that affect this task are:

o   The task definition is ill-defined. This causes Natalia to have to interpret the intention of the task & how its results & recommendations will be used. Her interpretation could not be in line with management expectations & this tension requires Natalia to create a specific definition for the task that she is working on a solution to.

o   The task is under-constrained. Again, this causes Natalia to focus on developing a description of the boundaries of both the task & the solution; i.e. “what to leave in & what to leave out”.

o   Interpretation of the results & development of recommendations is somewhat intuitive rather than empirical. This is related to theoretical/pragmatic. Natalia must make recommendations that are feasible & that in turn will lead to results in finite time. The tension here is extreme as there are already many recommendations reported in the literature & the public press in this area as well as many expectations of what the “right” solution(s) may be. Natalia must be able to focus on interpretations & recommendations that are relevant & feasible for her organization & not based on general expectations or ideas in the public sphere.

o   The solution(s) may require structural (organizational) changes as well as functional (partly technological) changes. There is a tension in the balance between these that must be addressed.

o   Her manager has given Natalia two weeks (elapsed) to accomplish this task. Natalia has already told her manager that this is not enough time for anything other than a set of guesses, but there is a big strategy meeting coming up &,… There is usually this tension between time & completeness (that is often a proxy for accuracy/correctness).

o   As with most work tasks today, something that seems simple can actually be quite complex. Just count all the patients that have hypertension & figure out what it costs to treat them… simple. Not… First of all what is a patient? What definition do you use for hypertension (or any clinical condition)? What do you mean by cost? Does the cost accounting system even have patients in it? The more you peel this back the more complex it becomes. This means Natalia, once again has to be explicit about definitions for every important term as well as for each calculation. This means she can at least say that for this definition of these conditions & comorbidities & for this definition of the calculation of costs, this is the median cost in 2014 of treating this comorbidity for the 2,146 patients recorded with it.

o   This task can be interpreted at a tactical level: what are the relatively small changes that can be made to our clinical workflows & financial processes that will enable us to reduce costs? It can also be interpreted at the strategic level: what are the organizational & large-scale technology changes that can be made that would allow us to systemically reduce costs? As with all of these contradictions, there is a balance to be had here as well.

o   Finally, in healthcare there is a purely strategic & almost unmentionable contradiction that is very well illustrated by this task – that is cost reduction versus improvement in patient outcome. These are not necessarily mutually exclusive, but the trade-offs made, especially when resource constrained (think dollars) can make it seem as if they are. Does reducing the cost of treatment on a per patient or per condition basis improve or worsen patient outcomes. Certainly we do not want to have worse outcomes at the “cost” of cost reduction, but it often seems as if this is the choice. There is enough fat & waste in the healthcare system that these do not have to be mutually exclusive, but this kind of general statement does not work on a per patient basis. The tension here can be extreme.

Natalia’s work on this task does appear to be very aligned with our description of design work process. Can we learn something from how designers work to make her work more effective, or even more efficient? Also, I hear you say, “what about strategy, I thought this was about strategy.” Right, lessons learned first…

Several relatively recent sources have looked at these lessons from different perspectives these include a 2007 report on how global brands use the design process to create leverage & competitive advantage[12] & several Harvard Business Review articles[13].

A primary lesson described in both reports is that design must be tightly tied to & aligned with the end user experience – not the technology used, general design trends or management expectations. This requires both knowing who the end users will be & creating an experience that is compelling & useful for them in both functional & emotional ways. This is the case whether you are designing new communication devices or, as Natalia is, designing a solution & recommendations for strategic decision-making.

A second lesson is that models & prototypes are essential in the design process, & that they do different things. Models allow you to describe & examine the problem space; while prototypes allow you explore the solution. Models & prototypes should be readily available to people who are using or evaluating the work & feedback loops must be part of the process so that criticism & suggestions from feedback can be incorporated.

Design processes also tend to be optimal as collaborative processes. Teams may be co-located or distributed, but that cross-functional collaboration improves results & outcomes of projects. In Natalia’s case, she is working as an individual contributor but may, in fact collaborate in areas that she is not as experienced in such as development of financial models.

Finally, several challenges have also been incorporated as lessons:

• Larger amounts of ambiguity must be accepted by both end users & peers of the designer
• The same is true of risk
• Expectations must be set appropriately – design process is effective at reducing complexity, facilitating innovation & identifying future trends. It can also be effective at producing solutions to complex problems, as in Natalia’s case. It is not so good at actually operating a business. Even design companies like frog[14] & ideo[15] have business processes for program management, financial management etc.

OK, you say, but you promised strategy… There are two aspects to this. The first is that a strategy is a designed object & needs to be developed through a design process. The second is that design process itself is a strategy that can be adopted by organizations. I’ll deal with both of these.

As a designed object, an organization’s strategy needs to have certain characteristics. The primary one of these is that it is focused on a user end-state. What does the organization want to accomplish. What experience is it trying to create for the users of its product or service? Often organizational strategies, especially those of for-profit companies, are specified with respect to how much growth they need to achieve, what industry segments they’ll penetrate & by how much, how much revenue & profit they’ll generate. These are not a strategy but rather the results of a strategy. Strategy can be designed by collaboratively iterating descriptions & tactics (prototyping) & continuously modifying the strategy according to criticism & feedback. As we have seen, such a process must incorporate the acceptance of higher levels of ambiguity & risk in order to succeed. Once such a strategy is developed & decided upon, tactics & business processes must be developed to initiate & evolve the strategy.

What we are talking about is using the design work process to develop the organization’s strategy, so that the strategy is a designed object. We can also see, through this effort, that the design work process itself can be a strategy that is applied to many of the efforts & work tasks that an organization undertakes. This was shown in Natalia’s work example above. Using the design work process as a framework:

• Episodic & iterative approach so that multiple tasks are worked on at once

o   Use of models for problem description & prototyping for solution exploration

•  Classification & utilization of deep & large volumes of knowledge

o   Requires ways of searching, storing, analyzing & utilizing such knowledge

• Use of a broad variety of modeling, prototyping & problem-solving methods

o   Provides the best possibility of interpreting & presenting actionable results

• Allowing for the recognition, maintenance & resolution of the contradictions inherent in work efforts (as described above)

o   Recognition of contradictions allows for important aspects of a work task or problem to be identified & described

o   Maintenance of such contradictions allows for appropriate levels of ambiguity & risk to be maintained so that solutions are not tracked into & collapsed prematurely, &

o   Resolution of such contradictions allows solutions to be derived

These general characteristics outline a framework for addressing work tasks, up to & including strategy development that organizations can productively use. By looking at both the development of strategy & the accomplishment of work tasks as design problems, people (working in organizations or independently) can use a highly flexible model of work process to provide leverage in design, development, modification & measurement of work & work process. When I say “organizations will need to…”, I actually am talking about the people in those organizations who will need to be more tolerant of ambiguity & risk, understand that their work will be accomplished interatively & in episodes rather than in a single effort, be able to work with large amounts of information & knowledge & apply a broad set of problem-solving tools, applications & ways of thinking to creating solutions. Organizations that encourage & facilitate this approach to work & strategy, & that are made up of people that can utilize the design work model will be very well positioned to compete successfully as how we do our work, & even what our work is evolves over the next 5, 8, 10 years.

---

[1] Professor of Graphic Design, Yale University, 1956-1969, 1974-1985.

[2] M.C. Escher. Drawing Hands, 1948

[3] 1944-2010, Former Dean of the School of Architecture & Planning, MIT

[4] currently Patrick J. McGovern Professor of Management, Sloan School of Management, MIT

[5] Former Provost & Dean of Engineering, currently Institute Professor, MIT

[6] formerly Dean of the Graduate School of Design & currently Harvard University Distinguished Professor, Harvard University

[7] Knowledge work can be differentiated from other forms of work by its emphasis on "non-routine" problem solving that requires a combination of convergent, divergent, and creative thinking. https://en.wikipedia.org/wiki/Knowledge_worker

[8] Amazon.com lists 16,547 books under this topic ranging from The Critique of Pure Reason. Immanuel Kant. 1781, to The Future of Work – Human Value in a Digital World. Marcus Clarke. February, 2015. Accessed 18 August 2015.

[9] Knowledge work can be differentiated from other forms of work by its emphasis on "non-routine" problem solving that requires a combination of convergent, divergent, and creative thinking. https://en.wikipedia.org/wiki/Knowledge_worker. Accessed 15 August 2015.

[10] D. Lavoy. 2014. Is collaboration limited by organizational structure. http://www.cmswire.com/cms/social-business/is-collaboration-limited-by-organizational-structure-024450.php CMS Newswire, March 2014. accessed 10 September 2015.

[11] all definitions are from The American Heritage Dictionary of the English Language, 3rd Edition. 1992

[12] Eleven Lessons – Managing the Design Process in Global Brands: A study of the Design Process. Design Council. 11/2007.

[13] Design for Action. T. Brown & R. Martin. Harvard Business Review. pp. 56-65

     Design Thinking Comes of Age. Jon Kolko. Harvard Business Review. pp. 66-71. 11/2015.

[14] www.frogdesign.com/

[15] www.ideo.com/