Fig. 4.1
Illustration of the complex inter-relationships between the 8 dimensions of the new socio-technical model (Used with permission from: Menon et al. 2014)
In our model, one cannot expect to gain an in-depth understanding of the intricacies of complex HIT interventions simply by integrating the results of studies performed within any single dimension of the model (Rasmussen 1997). Rather, HIT interventions must be understood in the context of their simultaneous effects across multiple dimensions of the model. For instance, a recent evaluation of a national program to develop and implement centrally stored electronic summaries of patients’ medical records in the UK revealed their benefits to be lower than anticipated. The report cautioned that complex interdependencies between many socio-technical factors at the levels of the clinical encounter, organization, and the nation at large are to be expected in such evaluations (Greenhalgh et al. 2010). These study findings are illustrative of how and why our proposed model could be useful.
The 8 dimensions include:
1.
Hardware and Software Computing Infrastructure. This dimension of the model focuses solely on the hardware and software required to run the applications. The most visible part of this dimension is the computer, including the monitor, printer, and other data display devices along with the keyboard, mouse, and other data entry devices used to access clinical applications and medical or imaging devices. This dimension also includes the centralized (network-attached) data storage devices and all of the networking equipment required to allow applications or devices to retrieve and store patient data. Also included in this dimension is software at both the operating system and application levels. Finally, this dimension of the model subsumes all the machines, devices, and software required to keep the computing infrastructure functioning, such as the high-capacity air conditioning system, the batteries that form the uninterruptable power supply (UPS) that provides short-term electrical power in the event of an electrical failure, and the diesel-powered backup generators that supply power during longer outages.
In short, this dimension is purely technical; it is only composed of the physical devices and the software required for keeping these devices running. One of the key aspects of this dimension is that, for the most part, the user is not aware that the majority of this infrastructure exists until it fails (Leveson and Turner 1993). For example, in 2002 the Beth Israel Deaconess Medical Center in Boston experienced a 4-day computer outage due to old, out-of-date computer equipment coupled with an outdated software program designed to direct traffic on a much less complex network. Furthermore, their network diagnostic tools were ineffective because they could only be used when the network was functioning (Kilbridge 2003).
2.
Clinical Content. This dimension includes everything on the data-information-knowledge continuum that is stored in the system (i.e., structured and unstructured textual or numeric data and images that are either captured directly from imaging devices or scanned from paper-based sources) (Bernstam et al. 2010). Clinical content elements can be used to configure certain software requirements. Examples include controlled vocabulary items that are selected from a list while ordering a medication or a diagnostic test, and the logic required to generate an alert for certain types of medication interactions. These elements may also describe certain clinical aspects of the patients’ condition (e.g., laboratory test results, discharge summaries, or radiographic images). Other clinical content, such as demographic data and patient location, can be used to manage administrative aspects of a patient’s care. These data can be entered (or created), read, modified, or deleted by authorized users and stored either on the local computer or on a network. Certain elements of the clinical content, such as that which informs clinical decision support (CDS) interventions, must be managed on a regular basis (Sittig et al. 2010b).
3.
Human-Computer Interface. An interface enables unrelated entities to interact with the system and includes aspects of the system that users can see, touch, or hear. The hardware and software “operationalize” the user interface; provided these are functioning as designed, any problems with using the system are likely due to human-computer interaction (HCI) issues. The HCI is guided by a user interaction model created by the software designer and developer (Shneiderman et al. 2009). During early pilot testing of the application in the target clinical environment, both the user’s workflow and the interface are likely to need revisions. This process of iterative refinement, wherein both the user and user interface may need to change, must culminate in an HCI model that matches the user’s modified clinical workflow. For example, if a clinician wants to change the dose of a medication, the software requires the clinician to discontinue the old order and enter a new one, but the user interface should hide this complexity. This dimension also includes the ergonomic aspects of the interface (Svanæs et al. 2008). If users are forced to use a computer mouse while standing, they may have difficulty controlling the pointer on the screen because they are moving the mouse using the large muscles of their shoulder rather than the smaller muscles in the forearm. Finally, the lack of a feature or function within the interface represents a problem both with the interface and with the software or hardware that implements the interface.
4.
People. This dimension represents the humans (e.g., software developers, system configuration and training personnel, clinicians, and patients) involved in all aspects of the design, development, implementation, and use of HIT. It also includes the ways that systems help users think and make them feel (Sittig et al. 2005a). Although user training is clearly an important component of the user portion of the model, it may not by itself overcome all user-related problems. Many “user” problems actually result from poor system design or errors in system development or configuration. In addition to the users of these systems, this dimension includes the people who design, develop, implement, and evaluate these systems. For instance, these people must have the proper knowledge, skills, and training required to develop applications that are safe, effective, and easy to use. This is the first aspect of the model that is purely on the social end of the socio-technical spectrum.
In most cases, users will be clinicians or employees of the health system. However, with recent advances in patient-centered care and development of personal health record systems and “home monitoring” devices, patients are increasingly becoming important users of HIT. Patients and/or their caregivers may not possess the knowledge or skills to manage new health information technologies, and this is of specific concern as more care shifts to the patient’s home (Henriksen et al. 2009).
5.
Workflow and Communication. This is the first portion of the model that acknowledges that people often need to work cohesively with others in the healthcare system to accomplish patient care. This collaboration requires significant two-way communication. The workflow dimension accounts for the steps needed to ensure that each patient receives the care they need at the time they need it. Often, the clinical information system does not initially match the actual “clinical” workflow. In this case, either the workflow must be modified to adapt to the HIT, or the HIT system must change to match the various workflows identified.
6.
Internal Organizational Policies, Procedures, Environment, and Culture. The organization’s internal structures, policies, environment, and procedures affect every other dimension in our model. For example, the organization’s leadership allocates the capital budgets that enable the purchase of hardware and software, and internal policies influence whether and how offsite data backups are accomplished. The organizational leaders and committees who write and implement IT policies and procedures are responsible for overseeing all aspects of HIT system procurement, implementation, use, monitoring, and evaluation. A key aspect of any HIT project is to ensure that the software accurately represents and enforces, if applicable, organizational policies and procedures. Likewise, it is also necessary to ensure that the actual clinical workflow involved with operating these systems is consistent with policies and procedures. Finally, internal rules and regulations are often created in response to the external rules and regulations that form the basis of the next dimension of the model.
7.
External Rules, Regulations, and Pressures. This dimension accounts for the external forces that facilitate or place constraints on the design, development, implementation, use, and evaluation of HIT in the clinical setting. For example, the passage of the American Recovery and Reinvestment Act (ARRA) of 2009, which includes the Health Information Technology for Economic and Clinical Health (HITECH) Act, made available over 20 billion dollars for healthcare practitioners who become “meaningful users” of HIT. Thus, ARRA introduced the single largest financial incentive ever to facilitate electronic health record (EHR) implementation. Meanwhile, a host of federal, state, and local regulations govern the use of HIT. Examples include the 1996 Health Insurance Portability and Accountability Act (HIPAA), recent changes to the Stark Laws,1 and restrictions on secondary use of clinical data. Finally, there are three recent national developments that have the potential to affect the entire healthcare delivery system in the context of HIT. These include: (1) the initiative to develop the data and information exchange capacity to create a national health information network (American Recovery and Reinvestment Act of 2009); (2) the initiative to enable patients to access copies of the clinical data via personal health records (Sittig 2002); and (3) clinical and IT workforce shortages (Detmer et al. 2010).
8.
System Measurement and Monitoring. This dimension has largely been unaccounted for in previous models. We posit that the effects of HIT must be measured and monitored on a regular basis. An effective system measurement and monitoring program must address four key issues related to HIT features and functions (Leonard and Sittig 2007). First is the issue of availability – the extent to which features and functions are available and ready for use. Measures of system availability include response times and percent uptime of the system. A second measurement objective is to determine how clinicians are using the various features and functions. For instance, one such measure is the rate at which clinicians override CDS warnings and alerts. Third, the effectiveness of the system on healthcare delivery and patient health should be monitored to ensure that anticipated outcomes are achieved. For example, the mean HbA1c value for all diabetic patients in a practice may be measured before and after implementation of a system with advanced CDS features. Finally, in addition to measuring the expected outcomes of HIT implementation, it is also vital to identify and document unintended consequences that manifest themselves following use of these systems (Ash et al. 2004). For instance, it may be worthwhile to track practitioner efficiency before and after implementation of a new clinical charting application (Bradshaw et al. 1989). In addition to measuring the use and effectiveness of HIT at the local level, we must develop the methods to measure and monitor these systems and assess the quality of care resulting from their use on a state, regional, or even national level (Sittig et al. 2005b; Sittig and Classen 2010).
4.4 Relationships and Interactions Among Components of the Socio-technical Model
Our research and experience has led us, and others, to conclude that HIT-enabled healthcare systems are best treated as complex adaptive systems (Begun et al. 2003). The most important result of this conclusion is that hierarchical decomposition (i.e., breaking a complex system, process, or device down into its components, studying them, and then integrating the results in an attempt to understand how the complete system functions) cannot be used to study HIT (Rouse 2008). As illustrated by the evaluation of centrally stored electronic summaries in the UK, complex interdependencies between various socio-technical dimensions are to be expected, and our HIT model (had it existed at the time) might have potentially predicted some of them and allowed them to be addressed prior to going-live rather than in the evaluation stages of the project. Therefore, one should not view or use our model as a set of independent components that can be studied in isolation and then synthesized to develop a realistic picture of how HIT is used within the complex adaptive healthcare system. Rather, the key to our model is how the 8 dimensions interact and depend on one another. They must be studied as multiple, interacting components with non-linear, emergent, dynamic behavior (i.e., small changes in one aspect of the system lead to small changes in other parts of the system under some conditions, but large changes at other times) that often appears random or chaotic. This is typical of complex adaptive systems, and our model reflects these interactions.
For example, a computer-based provider order entry (CPOE) system that works successfully in an adult surgical nursing unit within a hospital may not work at all in the nearby pediatric unit for any number of potential reasons, including: (1) hardware/software (e.g., fewer computers, older computers, poor wireless reception, poor placement); (2) content (e.g., no weight- or age-based dosing, no customized order sets or documentation templates); (3) user-interface (e.g., older workforce that has trouble seeing the small font on the screen); or (4) personnel (e.g., no clinical champion within the medical staff). However, each of these dimensions has a potential relationship with one or more of the other dimensions. For instance, computers may have been few or old because of some organizational limitations on financing, a constrained physical environment that results in limited space in the patient rooms or even the hallway for workstations, or a combination of these restrictions, there may be no customized order sets because clinician-users did not agree on how best to create them or on the medical evidence to support their decisions, and there was no clinical champion because the organization did not provide any financial incentive for the additional time this role would entail. Other reasons could include problems with the user interface and the communication and workflow related to how nurses process new medication orders using the EHR and record administration of medications using the new barcode medication administration system. These issues, in turn, may have been due to long-standing organizational policies and procedures that administrators were reluctant to reconsider. For example, the unit governance committee may have decided not to approve a request for mobile computers to help compensate for the lack of hardwired, stationary workstations in the patient rooms, with the result that nurses spent more time away from patients and therefore had a slower workflow related to processing new orders. The preceding example illustrates the interaction of six dimensions of our model: hardware/software, clinical content, user interface, people, workflow, and organizational policies. Additionally, some form of system measurement and monitoring could have detected these issues. In summary, our model provides HIT researchers with several new avenues of thinking about the interactions between key technology and social components of the HIT-enabled work system and how the interactions between the various socio-technical dimensions of our model must be considered in future research.
4.5 Applications of the Socio-technical Model in Real-World Settings
The following sections illustrate how we have used the socio-technical model of safe and effective HIT use within our research. In an attempt to describe how the model can be applied across the breadth of HIT research and development, and to provide examples of different systems and interventions that can be analyzed within this new paradigm, we highlight key elements of our model in the context of several recent projects.
4.5.1 HIT Design and Development
The design and development of CDS interventions within clinicians’ workflow presents several challenges. We conducted several qualitative studies to gain insight into the 8 dimensions of our model during the development of a CDS tool within a CPOE application. This CDS intervention was designed to alert clinicians whenever they attempted to order a medication that was contraindicated in elderly patients or a medication that had known serious interactions with warfarin. For example, Fig. 4.2 shows a pop-up alert which appeared whenever a clinician attempted to order “diazepam” on a patient who was 65 years or older.
Fig. 4.2
An example pop-up alert warning a user that diazepam is not a preferred benzodiazepine for a patient 65 years or older (Used with permission from: Smith et al. 2006)
We used several methods, including focus groups, usability testing, and educational sessions with clinician users (Feldstein et al. 2004), to identify issues related to hardware/software, content, interface, people, measurement, workflow/communication, and internal policies and procedures. These efforts helped us, for example, to understand the need to meet with the organization’s Pharmacy and Therapeutics committee (i.e., internal policy) to convince them to modify the medication formulary to include an alternative suggestion for specific medications contraindicated in the elderly. We also worked with the information technology professional (i.e., people) who was responsible for maintaining the textual appearance (i.e., font size – an element of the user interface) of the alerts as well as the content of the message, and the order of the messages. Fitting alert content within the constraints of the alert notification window (i.e., user interface) eliminated the need to train clinicians to use the horizontal scrolling capability. This is just one simple example of how use of the socio-technical model paid huge dividends during the development and implementation stages of this highly successful project (Feldstein et al. 2006; Smith et al. 2006).
4.5.2 HIT Implementation
In a separate study, we derived lessons that could be learned from CPOE implementation at another site (Sittig et al. 2006). One of the most important conclusions from this implementation was that problems could, and often do, occur in all 8 dimensions of the model. In addition, many of the problems resulted from interactions between two or more dimensions of the model (see Table 4.1) (Sittig and Ash 2010).
Table 4.1
Applications of the socio-technical model to analyze two HIT-related interventions
Socio-technical model dimension | Implementation of computer-based provider order entry | Follow-up of alerts related to abnormal diagnostic imaging results |
|---|---|---|
Hardware and software | The majority of computer terminals were linked to the hospital computer system via wireless signal. Communication bandwidth was often exceeded during peak operational periods, which created additional delays between each click on the computer mouse | Alerts should be retracted when the patient dies or if the radiologist calls, or the patient is admitted before the alert is acknowledged. However, this can be done only through a centralized organizational policy |
Clinical content | No ICU-specific order sets were available at the time of CPOE implementation. The hurried implementation timeline established by the leaders in the organization prohibited development of these order sets | Interventions to reduce alert overload and improve the signal to noise ratio should be explored. Unnecessary alerts should be minimized. However, people (physicians) may not agree which alerts are essential and which ones are not (van der Sijs et al. 2008) |
Human computer interface | The process of entering orders often required an average of 10 clicks on the computer mouse per order, which translated to 1–2 min to enter a single order. Organizational leaders eventually hired additional clinicians to “work the CPOE system” while others cared for the patients | Unacknowledged alerts must stay active on the EHR screen for longer periods, perhaps even indefinitely, and should require the provider’s signature and statement of action before they are allowed to drop off the screen. However, providers might not want to spend additional time stating their actions; who will make this decision? |
People | Leaders at all levels of the institution made implementation decisions (re: hardware placement, software configuration, content development, user interface design, etc.) that placed patient care in jeopardy | Many clinicians did not know how to use many of the EHR’s advanced features that greatly facilitated the processing of alerts, exposing a limitation in provider training. Adding to the problem, providers are only given 4 h of training time by the institution |
Workflow and communication | Rapid implementation timeline did not allow time for clinicians to adapt to their new routines and responsibilities. In addition, poor hardware and software design and configuration decisions complicated the workflow issues | Communicating alerts to two recipients, which occurred when tests were ordered by a healthcare practitioner other than the patient’s regular PCP, significantly increased the odds that the alert would not be read and would not receive timely follow-up action. No policy was available that states who is responsible for follow-up. |
Organizational policies and procedures | Order entry was not allowed until after the patient had physically arrived at the hospital and been fully registered into the clinical information system | Every institution must develop and publicize a policy regarding who is responsible (PCP vs the ordering provider, who may be a consultant) for taking action on abnormal results. Such policies also help institutions meet external (i.e., Joint Commission) requirements |
External rules, regulations, and pressures | Following the Institute of Medicine report To Err is Human: Building a Safer Health System and subsequent congressional hearings, the issue of patient safety has risen to a position of highest priority among health care organizations | Poor reimbursement and heavy workload of patients puts productivity pressure on providers. The nature of high-risk transitions between health care practitioners, settings, and systems of care makes timely and effective electronic communication particularly challenging |
System measurement and monitoring | Monitoring identified a significant increase in patient mortality following CPOE implementation
 Stay updated, free articles. Join our Telegram channel
Full access? Get Clinical Tree
Get Clinical Tree app for offline access
|