• General information
• Educational opportunities
• Projects and activities
• Jobs and career information
• Publications
• Faculty and staff
• Alumni Connection
• Archives

CHAPTER IV

THE SYSTEM DESIGN

Introduction to the System Design Process

The goal of this study was to produce a design and a conceptual framework for an advanced informatic system that would be capable of helping Americans improve their health status and quality of life. The first three chapters focused on the context of the lifestyle-related health problems of Americans, the literature pertaining to the theoretical and scientific base of health, behavior change, and the informatic sciences, and a description of the methodology and process that was used to design the model system.

Chapter IV is a concise report, presentation, and discussion of the synthesized data and results from SDLC design process. A detailed description of the five-step SDLC methodology that was used for the system design process was presented in Chapter III. All of documentation from the entire SDLC process is contained in the Appendices and the supporting documentation (Studach, 2000). The four major products of the design process that are included in this chapter are: the results of the SDLC process, a summary of the most important points from the synthesized data, a narrative description with illustrations of the system model, and an exploration of the alternative paths to adoption.

Identifying the Problem, Opportunities, and

Objectives - SDLC Step # 1

The first step of the SDLC process called for a definition of the problem, a listing of the potential opportunities, and a description of the objectives on which the system is based. The data in this section correspond to and partially fulfill the first and second research objectives.

The Problem

Generally, how an individual or organization views the problem is related to whether the person or entity is involved primarily with outcomes-related activities, such as dealing with, addressing, or resolving the health problem, or, conversely, is more involved with the process-related activities, such looking at potential solutions or systems design, implementation, support, and evaluation issues. In this study, both perspectives of the problem are related to the lack of an advanced health promotion informatic system that is sufficiently capable of improving the health-related lifestyle behavior choices of individuals on a population-wide basis.

The problem from the first perspective, the outcomes worldview, is grounded in the theory and concepts of health promotion. In this perspective stakeholders such as consumers, practitioners, providers, or policy makers are primarily concerned with health-related outcomes. These healthcare agents focus on the outcomes problems or the health-related conditions that a model system is designed to target, influence, or improve.

Most health problems and issues are highly complex and have implications and interrelationships throughout the healthcare system. However, in this study the outcomes side of the health problem is defined as the habits, behaviors, and lifestyle choices of individuals and populations that prevent the attainment of optimal levels of health and well-being, that compromise their health status, increase their risk, or that lead to negative consequences for their quality of life. Further, it is worth noting that this perspective is based on and is consistent with the aspirations, goals, and recommendations from a variety of highly respected taskforces, national bodies, and agencies such as the Healthy People 2000 initiative, the CDC's disease prevention and promotion guidelines, the Institute of Medicine, the Agency for Health Care Policy Research, the Center for the Advancement of Health, and the Healthy Cities project (United States Department of Health and Human Services, 2000; Health Care Financing Agency, 2000; Center for the Advancement of Health, 2000, Smedley et al., 2000, Centers for Disease Control, 2000; Duhl, 1996).

In the second perspective, the process perspective, the stakeholders would be members of a design and development team that would traditionally be involved in a project of this type, and they would view the problem from a design, process, development, technology, or solution orientation. Systems and software designers and developers; computer, telecommunications, and IT specialists; data managers and informaticists, and researchers are among the stakeholders that would be part of a design and development team. Managers of the business side of the systems development and implementation process would also play an influential roll in the design process.

From the process perspective, the problem is defined as how to best design a system that will operate optimally, efficiently, and effectively. Process-related problems were identified, described, and discussed throughout the data collection process as well as in great detail in the literature. However, because of the nature and complexity of the system that is envisioned, it is impractical to provide a detailed listing of all of the issues, elements, and subproblems that are within the scope of this study. Therefore, only a few of the most significant problems and issues that are prominent at one or more of the decision-making stages of the design process are highlighted below.

A non-prioritized short list of the process problems that were considered during the design process can be grouped into six broad categories. Many of the elements that are listed below overlap across several categories.

• The design category includes problems and issues such as inadequacies, incompatibilities, and limitations of design theories and models and cross-domain, transdisciplinary, and intradisciplinary questions.
• The development category problems and issues, many of which are shared with several other categories, include project and team management issues as well as system and software design issues such as standardization, portability, and the interoperability of code and systems, modularization, and prototyping of systems.
• Data management and informatics is a category that includes many issues and problems such as data integrity, flow, and management, data optimization, user interface and control concepts, as well as overall design issues.
• There are many problems in the computer science, information technology, and telecommunications domain including software, hardware and issues such as cross-platform performance, interoperability, extensibility, portability, as well as security concerns.
• The research concerns include theory, study integrity and designs, quantification and replication of results, and exploration of future research topics.
• The business and evaluation problems and issues that encompass metrics and the bottom line considerations that are most often key to the ultimate success of projects.

The list of problems and issues cited above is neither exhaustive nor validated on a single framework. However, each of the problems and issues were considered during the design and decision-making process. The breadth of problems on the list does help to illustrate how difficult it is to address such a diverse array of difficulties and balance them in designs and conceptual frameworks that are simple, comprehensive, and complete. The problems that are reflected in the main themes for the conceptual framework and the system design are presented in the following sections.

Opportunities

A host of potential opportunities were identified during the data collection process. The opportunity data were collected from multiple sources including reviews of the literature, brainstorming and critiquing sessions, case studies, pilot testing of products and systems from the market place, and interviews with leaders in the field. The non-prioritized short list of opportunities and benefits that could be realized from the development and deployment of an advanced health promotion informatic system have been grouped according to four stakeholder groups.

1. Consumers and users

• To be able to achieve dramatic improvements in health status and quality of life through lifestyle changes
• To empower users to care for their health
• To provide access to powerful support networks

2. Practitioners, agents, and sponsors of the healthcare system

• To address health problems in a more comprehensive and proactive way
• To fully integrate the healthcare supply chain
• To streamline the healthcare process
• To reduce the personal health and economic burden
• To reengineer the healthcare by integrating technology throughout the spectrum of care
• To foster more efficient allocation of resources
• To explore the pilot testing of new delivery and business models

3. Technologists and informaticists

• To provide test beds and a vehicle for pushing the "technology envelope"
• To advance and help in testing open systems concepts
• To build design and development teams and experts that understand both sides of the problem and the issues related building to viable solutions

4. Researchers

• To develop systems and models for testing effect and efficacy
• To provide a venue for refining and testing models and theories

In short, there are ample opportunities for addressing the problems and achieving the mission and goals that are listed below by engaging in the process of designing a model system. The novel conceptual framework and the system design that is envisioned for this project would fill part of the void that currently exists.

Objectives

The Mission

In this study, the objectives and goals emanate from a core mission. In the opinion of the researcher, the stated mission for developing a health promotion informatic system is to provide a highly innovative, efficient, and effective use of technology for the improvement of the health status and quality of life of Americans. Several additional benefits such as empowering consumers, improving the overall access to and quality of service and care, as well as improved efficiency and savings in all aspects of the healthcare system may accrue for individuals, organizations, and society from the proposed system.

The Goals

Since this is a design study and the measurement of specific objectives is beyond the scope of this investigation, the objectives were stated as a set of goals. The five goals formed a set of fundamental principles for the proposed system and the conceptual framework. The non-prioritized list of goals that evolved from the mission statement is:

1. To empower consumers;
2. To progress toward improving and ideally optimizing the health status and quality of life in individuals and target population groups;
3. To work to reduce the level of health-related human burden and economic costs for individuals, organizations, and society;
4. To embed effective dynamic state-of-the-art advanced informatic technologies in a system, that is based on the best and evidence-based practices of the behavioral and informatic sciences, that features a comprehensive array of services, and that is founded on a model of optimal wellness and lifelong care; and
5. To learn about and explore what is possible and practical from the development and implementation of the next generation of health-enhancing systems.

In summary, in the first step of the SDLC process, the two types of problems to be addressed in the model system design are, first, the health-related outcomes problems and, second, the technology and design process problems. Goals for the proposed system were generated from two sources; the opportunities that are possible because of the development and implementation of the system that is envisioned and the mission statement that is related to the design of the model system. The problems, opportunities, and objectives served as the basis for defining the system requirements in SDLC step #2.

Determining the System Requirements - SDLC Step #2

Introduction to the System Requirements Process

The second step in the SDLC methodology called for a detailed assessment of the requirements for an effective system. The researcher collected the data, completed the requirement analysis process, and asked experts in the field to critique the requirements list.

The Volere Requirements Specification Template and Requirements Shell, a validated process development methodology that is complementary to the SDLC, was used to provide a structure for identifying and organizing the requirements of the system model (Robertson et al., 1999). A generic scenario was developed to illustrate how the system might function (SDLC step #2). The scenario and event list was used throughout the requirements definition process.

The 27-step Volere Requirements Specification Template specifies five requirement types that are necessary for a comprehensive examination of the requirements specification process. The five requirement types are: product drivers (the business-related forces), constraints (stipulations about how the product fits into the world), functional requirements (the fundamental subject matter of the system), non-functional requirements (the behavioral properties), and project issues (the conditions for the project). The system requirements were translated into the technical specifications and functional needs for the system during the third stage of the SDLC process. The data in this section correspond to and partially fulfill the first three research objectives.

The Fundamental Requirements

The raw data from the 27-step requirements process were recorded and are part the documentation for the system (Appendices or Appendices as a pdf file and Studach, 2000). The following is a non-prioritized synthesis of eight fundamental requirements that emerged from the requirements definition process.

1. Legal and ethical - Because of legal requirements and ethical standards in the United States, users must have full privacy, confidentiality, and security rights for their own personal and health record, data, and information during all transactions within the system. The rights and permissions to use the data and information must conform to the appropriate laws and jurisdictions and be explicitly granted by the user. The user may modify, withdraw, or revoke permissions at any time and the system must enforce the permission parameters for all transactions.
2. Error and harm reduction - Because of the possibility of harm to users of the system and potential for errors of all types within such a diverse and distributed environment, automated procedures, protocols, and mechanisms must be in place throughout the system to reduce the potential for harm and to minimize the possibility for errors to the fullest extent possible.
3. Data and knowledge bases - Because the process of highly-effective long-term behavioral change is founded on the concepts of stage-related processes, proactivity, goal-directed behavior, individualized decision support systems, the tailoring of content and services, and the provision of ongoing support, the system must be data and knowledge driven. In order to perform optimally, these sophisticated behavior change systems generally require access to and the strategic use of an array of psychographic and health-related data from a variety of relational and object-oriented data and knowledge bases.
4. User-centric - Because of the requirement that the system be designed to accommodate to the user, optimize the user-centric interface and experience, and minimize barriers for all users of the system, the system must be designed to be intelligent, dynamic, and able to tailor the interface, interactions, and output to the preferences and tastes of each user.
5. Linking affiliated systems - Because of the comprehensiveness and complexity of the requirements for the proposed system, the sources and types of data involved, and the number and diversity of the affiliated systems, an object-oriented design methodology and architecture is the most logical design paradigm for the system.
6. Open systems environment - Because the system requires such a diversity and array of operating systems, platforms, languages, applications, sources of vendors and types of computing and telecommunications devices and appliances, the entities and elements of the system must be able to conform to and operate in an open environment.
7. Efficiency of care and communication - Because of the importance of providing a continuum of care for promoting optimal wellness and a high quality of life, the value and impact of health-enhancing environments and support networks, and the need to improve the efficiency within the healthcare system, the system must promote and provide universal communication among users, practitioners, and agents of care as well as draw on the best and evidence-based practices of the healthcare and informatics domain.
8. Meets the systems objectives - Because of the complexity, sophistication, and task requirements of object-oriented system designs, the system must use intelligent agents to execute tasks that will enable the system to achieve its goals and objectives in order for the user to gain maximum benefit from using the system.

In summary, the requirements that emerged from the Volere requirements definition process represent all five types of requirements that are necessary for a comprehensive examination of the proposed conceptual framework and the system design. The analysis and synthesis process produced eight fundamental requirements that clearly differentiate this system from all others that are currently available in the market place. The requirements served as a framework for defining the needs of the system in SDLC step three.

Analysis of the System Needs - SDLC Step #3

Introduction to the Analysis of the System Needs Process

The goal of step 3 in the SDLC process was to complete the decision-making process about the technical and functional needs for the recommended system. This study followed the traditional practice of analyzing and then comparing the technical and functional elements and needs of several highly rated systems with the features and functionality of the proposed system. One set of system needs was recommended though the comparative analysis process. The intent of the analysis process was to incorporate that set of needs into the model system design and the conceptual framework in step 4 of the SDLC. The data in this section correspond to and partially fulfill the first three research objectives.

Analyzing the System Needs

The system needs are the specifications for the technical and functional requirements that are necessary that satisfy the eight requirement criteria that were described in requirements definition section of this chapter. Those requirements were deemed necessary in order to satisfy the needs of the users of the system and to address the problems that were identified in Chapter I and expanded upon in this chapter. The issues and details relating to the functional and technical needs of the systems were covered fully in SDLC step #3 Appendices or Appendices as a pdf file and Studach, 2000).

Three types of information systems were chosen for the systems comparison portion of the needs analysis. The three types of systems, the commercial Internet portals, the theory-based research projects, and the proposed system were selected because they represent a diverse set of approaches for addressing the needs of the consumer as well as very different levels of technology integration and complexity. The comparison ratings data for the functional and technical needs for the three types of systems are summarized in Table 5. Clearly, the proposed system received superior ratings for meeting the needs of the consumers and practitioners when compared to the other systems.

Table 5. Needs Analysis - Ratings of Functional and Technical Needs

	Functional Needs		Technical Needs
System type	Consumers	Practitioners	Consumers	Practitioners
Commercial portals	.35	.32	.26	.21
Research/Theory	56	.50	.58	.46
Proposed system	1	1	1	1

Technical Specifications

An important part of the process in SDLC step #3 was establishing a set of technical specifications that would serve as the fundamental building blocks for the system model and the conceptual framework in step #4. The technical specifications have been organized into four major headings, with the subheadings for the key attributes, and a brief description of the system highlights that emerged from the technical specification process (Appendices or Appendices as a pdf file SDLC step #3).

Design

• Environment - open techniques and environment
• Architecture - modular, multilayered, and N-tiered structure
• Object-oriented - design and modeling process
• Development - strategic, staged, and incremental methodology and techniques such as prototyping and iterative designs
• Interface - dynamic user-centric look and feel

Technical

• Central structure and interfaces - for functionality, interoperability, and performance
• Security - systematic integrated methodologies, protocols, tools, and techniques
• Telecommunications - flexible, scalable, and accommodating multipurpose infrastructure
• Networking - flexible, scalable, and accommodating topologies
• Programming languages and environments - open and portable

Data

• Access, control, and management - integration, security, and integrity of the data
• Rights and permissions - the user maintains control of their data
• Administration - protocols, procedures, and issues such as audit trails, fault tolerance, and backups etc.

Core Components and Modules

• Central structure - core principles, processes, procedures, rules, and instructions
• Devices for input and output - full spectrum of options
• Interface - accommodating, intelligent, dynamic, mulitmodal, and user-centric
• Data and knowledge bases and sources - all of the data and knowledge repositories
• Agents - intelligent software agents that perform a variety of automated tasks
• Service components - outputs in the form of services and products
• Tailoring module - data, inference engines, and knowledge bases for tailoring
• Affiliated systems - the supply chain network including practitioners and providers, sponsors, and agents of care
• Support - proactive help and technical support tools to enhance the functionality of the system for users

The technical needs listed above comprise a complete but not totally exhaustive list of specifications for the proposed system. Other elements as well as a further definition and refinement of the needs will arise as new products and options become available or mature and as the design and development process evolves. The list of technical is consistent with the problems, opportunities, objectives, the system requirements, and the system needs that were defined in SDLC step #1 - 3.

The Model System Design - SDLC Step #4

Introduction to the Design Process

In this study, the design for the model system and the conceptual framework were the products or outcomes of the step-by-step SDLC design process. All of the viable options, features, and components for the model system were identified, researched, evaluated, and the comparative worth or value of them to the system and the users were assessed in the first three steps of the SDLC.

There are two parts to the goal of the fourth step in the design process: first, to design the system, and, second, to present the reader with a clear picture of what the system looks like, to describe the parts of the system, to show how it is structured, and to illustrate how it might operate. The system will be described with narrative descriptions, illustrations, and examples including possible scenarios and a comparison of the system features with exemplary systems. The data in this section correspond to and fulfill the first four research objectives.

The System Model

The Core Concepts

Three types of descriptors will be used to highlight the central themes that are found throughout the model system. First, there are eight terms: secure, user-centric, proactive, intelligent, dynamic, optimized, tailored, and data-centric are the key words that capture the essence of the system. Evidence of these terms will be found in every feature, function, and module of the system.

Second, the system has been described as an advanced health-promoting informatic system. It is dramatically different from the types of systems that have been described elsewhere in this study Appendices or Appendices as a pdf file SDLC step #3 and Tables 3 and 4 in Chapter I). Several of the key attributes of the system have been summarized in the table below. The fact that all of these attributes are incorporated into one system is one of the most important characteristics that sets this system apart from the other options and systems that are currently available in the marketplace.

Third, the core concepts of the system are grounded in two sets of principles: first, the central themes that are summarized in the six core principles listed below, and second, the concepts and on the eight fundamental requirements of the system (Chapter IV).

Table 6. Key Attributes of the Advanced Health-Promoting System

Advanced	Health promoting	Informatic system
1. System-wide intelligence 2. Array of agents 3. Object-oriented 4. Array of integrated devices and appliances 5. Planned integration of next generation technologies 6. Proactive improvement mechanisms	1. Behavioral theory and evidence-based change 2. Optimal wellness 3. Data-driven tailored products and services 4. Proactive 5. Life-long continuum of care 6. Targeted interventions 7. Support networks 8. Array of practitioners and agents of care	1. User-centric interfaces 2. Data-centric 3. System-wide self-monitoring and error reduction mechanisms and audit trails 4. Fully-integrated components, modules, and features 5. Seamless and dynamic modifications and upgrading

1. The system must be grounded on the principles of health promotion; designed to promote life-long health-enhancing lifestyles, optimal wellness and qualify of life, and offer content, products, and services that are tailored to each user.

2. The system must conform to all laws and ethical standards; the users must consent to the system interventions and interactions with the system, they must maintain control over their personal data, and they may establish security rights and permissions about how the data is used.

3. The system must be user-centric and attempt to conform to, accommodate, and optimize the interactions with the system on the basis of the preferences and tastes of the user.

4. The system must continually work to minimize the potential for harm to the users and reduce errors within the system.

5. The system must be data- and knowledge-driven, be based on the best and evidence-based knowledge and practices of the health domain and the behavioral and informatic sciences, and encompass the data that it needs to perform optimally.

6. The system must be flexible, accommodating, and feature the best and most appropriate technologies that are available.

The Stakeholders and Scope of Work

Several key stakeholders groups were identified in the SDLC process. The system was designed primarily to server individuals, consumers, and users by promoting health-enhancing lifestyle behaviors. The Scope of Work and Work Context Diagram (Figure 2) illustrates how additional value will be generated by involving practitioners and agents of care, affiliated systems of the healthcare supply chain, providers and sponsors, developers, researchers, and policy makers through an inclusive system design.

The Scope of Work and Work Context Diagram (Figure 2) was particularly useful for illustrating the system boundaries and the relationships among the key entities of the system.

Several points about the diagram are worth highlighting. First, the placement of lifestyle, behavior, and stage of change at the center of the diagram indicates that influencing those dimensions is the primary goal of the system. Second, naming the other important entities that are connected to the system indicates that value is added to the system by involving and integrating these important entities of the healthcare process into the system. The bi-directional arrows illustrate that all of the components and entities in the system interoperate. Third, the dotted arrow indicates that the system is founded on a set of fundamental principles. Fourth, each of the major components of the system makes a contribution to the goals of the system.

The Context Flow

Another useful perspective of the system model and the elements is illustrated in the context diagram. The main system elements and the flow and context of the processes are represented in Figure 3, the Context Flow Diagram.

The highlights from the Context Flow Diagram are as follows:

1. The main focus of the system is the relationship between the system and the users.
2. The system has many users and the primary mission of the system is to provide content and services for the users.
3. Some of the system entities have been represented in groups because of common functionality.
4. The system has a full spectrum of entities that make up the healthcare supply chain that is connected to the system.
5. The system is linked to an array of practitioners and agents of care, some of whom work directly or indirectly with or for the users of the system.
6. The system has an array of databases which provide and serve as repositories for all forms of data that the system needs to function and accomplish its' goals in an optimal manner.
7. The family of knowledge bases provides an enormous amount of collective knowledge that the system continually draws on to ensure that it is using the best practices from each of the domains.
8. The family of agents continually performs functions for benefit of the system and the users.

The Scope of the Product

The Scope of the Product - A Use Case Diagram (Figure 4) is based on the generic scenario and the list of 20 events that was generated to represent a typical pattern or sequence of events for a user of the system. The Use Case Diagram was based on object-oriented design principles and was developed to illustrate the elements and entities of the system and how they would function and interrelate.
Several important points that are illustrated in the Use Case Diagram are worth highlighting.

1. Two human entities, the direct targets of the system (consumers and users) and those indirectly but intimately involved and integrated into the change process (practitioners and agents of care) are represented in the system.
2. The entities that share common attributes and characteristics are shown as system objects.
3. Intelligent software agents service all of the system elements, objects, and databases and execute a variety of tasks for the benefit of the user or the system as a whole.
4. The first three events: (1) -- "create_master_record"/ "create_unique_ID", (2) error/harm checking -- , and (3) consents, permissions, and security are significant because they provide a mechanism for linking the system elements; they establish a platform for tailoring; they ensure maximum safety for the system and the users, and they stipulate the fundamental system operating parameters.
5. The object-oriented attributes of the unique ID and the databases make it possible to track, assess, and optimize the progress of users, events, transactions, and interactions among the system modules.

The event list was set up to illustrate one linear unidimensional scenario. The event list from the scenario has been tested in a variety of sequences and configurations. However, because of all of the possible combinations and permutations in the event list, other possible events and a host of unpredictable factors, it is not possible to play out the event case list in an endless set of combinations and scenarios because that is beyond the scope of this study.

The Functional Requirements

The scenario and event list were used as a framework for defining several of the key the functional characteristics of the system, the most prominent of which are the data elements.

Data Elements - The Use Case Diagram (Figure 4) was used to identify the data elements and stores within the system. Using object-oriented concepts, several of the data elements were grouped according to data type, origin, and shared attributes. The Entity-Relationship Diagram (Figure 5) was constructed to illustrate the major functional relationships among the data for the system side of the model and the path of a service and content scenario from the user side of the system.

Non-functional Requirements

The "non-functional" attributes and characteristics of the system, in the mind of many users, are at least as important to them as the products and services it provides. In a significant portion of the population, it is the style, look, and feel of a system that initially attracts them to the product or is the reason they first subscribe to or purchase what the system has to offer. For many current and potential users, a low barrier or, in many cases, any barrier becomes a reason to abandon the system, or it may add to a reluctance to explore and exploit the full functionality of the system. In the non-functional part of the system design process, the art of design is often more important than the science. A few of the most significant non-functional product qualities of the model system are highlighted below.

The Look and Feel - The user interface of the system should look and feel to the user exactly like the user would want it to look and feel. The user should have a variety of options and styles for the interface, device, and appliance. User-centricity, one of the founding principles of the system, dictates that the system should try to accommodate to and adjust for each user instead of forcing a user to adjust to the system. Moreover, it should change seamlessly and dynamically as the skills and tastes of the user change; and by using techniques such as collaborative filtering, it should even try to anticipate and stay "one step ahead" of the user (Neilsen, 1998a). This can be accomplished through flexible design and architecture, determining user preferences, proactively monitoring use patterns, continually collecting and probing data streams, and assigning intelligent software agents do the work. In short, the system should appear highly attractive to all users and no user should be left behind. In fact, some traditional and non-technical options that are linked into the system by non-invasive sensors or communication devices should be available for individuals who are technologically averse or where system linkages would not be practical or possible.

Usability and Ease of Learning and Use - The principle of low or no barrier holds true for usability and ease of learning of the system. The system will feature multiple interface and technology window alternatives, each of which may have several graded levels of sophistication. The users will have the opportunity to choose the option that works best for them. For example, some users will prefer to work from and receive their content and services from a platform-independent computer. Others may opt for a primarily auditory format such as a call center, phone, wireless device, VCR or cassette tape, or a CD-ROM. Each device or appliance may proactively present users with a range of complexity and learning options. The low-tech devices and interfaces may be familiar to most of the population such as a telephone, TV, or radio. Others devices may require some form of training and learning such as a VCR, computer, or technical device. The learning, like the content and services, are packaged in a format that is appropriate for the device and the user. Examples of learning tools include built-in help, wizards, tutorials, assistant agents, on-line help, training classes, and special-interest or support groups.

Other Key Features

• Performance - Speed, memory, bandwidth, and length of play are among the important performance-related issues. The system should have a variety of options available to the user, and the system should always adjust to minimize the impact of the issues on the user. Agents will do much of that work.
• Precision - The system must take into account the accuracy concerns of the users. Users should expect near zero tolerance for faults and the highest levels of precision and accuracy from the system.
• Capacity - Massive amounts of data will reside on the array of data and knowledge bases that are distributed, yet within the scope of the system. The system will be expected to have sufficient capacity to store all of the data and content that are needed for the system to function optimally.
• Cultural - The multi-cultural makeup of the population in the United States dictates that the perspective of all people should be accommodated by the system. Ideally, the system will build on the strengths of this diversity.

The Scenarios

Six typical scenarios have been provided to illustrate the types of generic themes and the areas of health promotion that would be ideal situations where the system would be used. The objectives are offered as examples of a few of the types of aims and ways in which the system might be effective. In each case, one of the main objectives is to establish or nurture the link between the user and the system. More details about the scenarios are available in Table 12 and Appendices or Appendices as a pdf file.

• A pregnant/postpartum mother - 1. build on her instincts and desire to have a healthy child (promotion/prevention), 2. strengthen the maternal bond (emotional/spiritual), 3. prepare for reversing the effects of pregnancy (physical/psychological), and 4. establish a solid connection link with healthcare providers (follow-up care/periodic triggers/efficiency)
• New Year's resolution for an individual - 1. capitalize on an annual reachable moment, the wide-spread custom of making New Year's resolutions, and to facilitate reassessment of progress toward or adoption of healthier behaviors (periodic assessments/benchmarking), 2. establish a start date and realistic goals for a behavioral improvement program (goal setting/skill development), and 3. establish a customized and targeted program regime for change (programming/motivational)
• A sports physical for a teenager - 1. provide routine screening services (assessment/prevention), 2. capture, monitor, and update physiological and other data that are collected from the screening tests and history (data collection/benchmarking), 3. use the opportunity and eagerness of the participants to offer or link them into other services (links with affiliated systems/motivational), and 4. offer services that are specific to the athletic endeavor, to improve knowledge, success, performance, or coping during their season, and to generate enthusiasm for overall wellness and quality of life (content/ extended programming and services)
• A breast cancer survivor - 1. promote compliance with follow-up services and treatment regimes (compliance/prevention), 2. activate and strengthen bonds with support networks (support/emotional), and 3. provide opportunities for mentoring and community support (community/environmental)
• A young adult with family history - 1. educate, reinforce, or highlight the role of the genetics factors for families that have a history with diseases with a significant genetic component (education/empowerment), 2. promote use of routine screenings (screening/compliance), 3. provide agents of care with the data on health records that will allow them to track the development of disease conditions (data/records), and 4. promote lifestyle changes that can mediate the effects of genetic predisposition when possible (behavior change)
• An adult conducting an Internet search - 1. promote empowerment among users (empowerment), 2. secure permissions and capture preferences and use pattern data that can be used to build a personal profile (permissions/data gathering), and 3. generate interest and provide an entertainment for users that will encourage repeat visits to the site or use of the services (promotional/psychological)

The Exemplary Systems

Five very interesting systems were found during the course of this investigation. Each of the systems had features that caused them to stand out from the generic and commercial systems. A superficial listing of some of the key attributes, strengths, and weaknesses of the systems, when compared to the model system, have been highlighted in the table below. More details on the systems and the process that was used to arrive at the data in Table 7 can be found in the Appendices or Appendices as a pdf file.

Table 7. Attributes of Exemplary Systems

Product	Features	Shortcomings
CHESS - The Health Education Consortium - University of Wisconsin, Madison (Gustafson, 1997) (Mature theory/ research system)	Support network, modular, some best practices, exemplary design process, and modular ­ e.g. breast cancer, HIV/AIDS, and strong evaluation and clinical trials.	Based on crisis/disease management models, not data-driven, few affiliated systems linked, minimal error/harm reduction, no agents, not user-centric at interface level, and not very proactive.
Guardian Angel - MIT (Szolovitz et al, 1994) (Non-implemented system at the conceptual design stage)	Object-oriented architecture, multiple user appliances, data-driven, some caregiver linkages, lifelong commitment, and best-practices.	Extremely large, complex and sophisticated, not fully deployed, no proven business model, not user-centric, and not yet subjected to evaluation and implementation stages.
Health-O-Vision - The Comprehensive Cancer Center - U Michigan (Strecher, 1997b) (Evolving theory/ research system)	High entertainment value, diversity from the multiple screens and user levels, data-driven, usability testing, and few caregiver linkages.	Smaller system that is not integrated, not intelligent, no proven business model, no harm reduction mechanism, and permissions for the users are not dynamic.
OneLife - The American Heart Association (Bulger et al., 2000) (Evolving theory/ research system)	Tailoring of content, proactive, data-driven extended linkages with primary care givers, some best science, and some integration.	Based on medical model/disease management, not all affiliated systems are linked, lack of agents/intelligence, not all OO architecture, and primarily system-centric interfaces.
ProChange - Cancer Center - University of Rhode Island (Prochaska, 2000) (Evolving theory/ research system)	Tailoring of content, proactive techniques, environmental assessments, health-related behaviors, and a strong research component.	Smaller system that is not fully integrated, lacks user-centric interfaces and design, not OO architecture, and caregivers and affiliated systems are not linked into the system.

Alternative Paths to Adoption

There are a number of major factors and barriers that would prove to be insurmountable and prevent a realistic chance of wholesale adoption and implementation of this design except for a best case scenario. For example, there may be an ideal situation where there is a clear vision and solid long-term mandate from the most senior-level decision makers, where the need has reached critical levels, where there is an abundance of uncommitted talent and resources, and where the potential for benefit clearly outweighs the level of identifiable risk. However, there are very few of those situations in the real world. Therefore, a secondary analysis that looked at several alternative paths to adoption that would be more appropriate for most organizations was performed Appendicies or Appendices as a pdf file.

There were six parts to the secondary analysis. In the first step, five traditional paths to adoption were identified: (1) wholesale adoption, (2) rapid prototyping, (3) incremental, (4) evolutionary, and (5) wait/do nothing/outsource. In step two, the characteristics, implications, barriers, advantages and disadvantages were listed for each of the alternative paths (Table 8). Third, a set of scenarios for six typical entities that represent a diverse mix of sizes, types, and organizational goals was developed. In the fourth step, a hypothetical set of scores for organizational needs that correspond to the eight system requirements and scores for the capacity of the organization to develop the core competencies and modules of the model system were assigned for each of the six entities (Tables 13 - 14). The scores for the need-to-capacity and the risk-to-return data were summed, ranked, and matched to the characteristics of the entities as part of step five of the process (Tables 15 - 16). In the final step of the process, a scatter plot (Figure 7 in Appendices or Appendices as a pdf file and two tables (Tables 8 and 17) were produced that provided tailored paths of adoption for each of the system components and the advantages and disadvantages of each.

Table 8. Alternative Paths to Adoption for All Scenario Entities

Component	Wholesale	Prototyping	Incremental	Evolutionary	Do Nothing
Central structure		Military, Fortune, HiTech	#1 Reg. PH, University	Clinic
Array of devices		Military, HiTech		Reg. PH, Fortune	University, Clinic
User-centric interface		HiTech		Military	Reg. PH, University, Fortune, Clinic
Data and (DB) knowledge bases (KB)		Military, Reg. PH (DB), HiTech (DB)	Health (DB), Fortune (DB)	Reg. PH (KB), University (DB), Clinic (DB)	University (KB), Fortune (KB), Clinic (KB), HiTech (KB)
Intelligent agents			Military, HiTech	Fortune	Reg. PH, University, Clinic
Service components		Reg. PH, Military	Fortune, Clinic	HiTech	University
Tailoring module		Reg. PH, Military, Fortune, Clinic	University	HiTech
Affiliated systems		Military, Fortune, Reg. PH	University, Clinic	HiTech
Support network		Reg. PH, University, Military, Clinic	Fortune, HiTech

This table illustrates the worth of developing a process or an algorithm for an alternative path to adoption strategy for complex systems. This process or algorithm is very complementary to and has a nice fit with the other aspects of the SDLC design process. Moreover, it actually reflects a more realistic real-world adoption strategy than the all-or-nothing wholesale approach and it is consistent with some of the recent adoption research from the information technology sector (Hocking, 1998).

Documentation for the System and the Design Process - SDLC Step #5

A full set of supporting design and operational documentation is particularly important for any system that is as sophisticated, complex, and comprehensive as has been outlined in this study. The entire SDLC design process and other supporting documentation has been posted online (Studach, 2000) and a condensed version of the key elements has been included in Appendicies or Appendices as a pdf file.

In addition, all operational documentation that is generated as the system evolves, is developed further, and is evaluated during the testing stages will be maintained and archived. The documentation that is referred to this section corresponds to and fulfills the fifth research objective.

Links to the SDLC methodology.

• SDLC - Step #1 - Identifying the Problem, Opportunities, and Objectives. Updated: December 27, 2000.
• SDLC - Step #2 - Determining the System Requirements Updated: December 27, 2000
• SDLC - Step #3 - Analysis of the System Needs Posted: December 27, 2000
• SDLC - Step #4 - Designing the Recommended System Posted: December 27, 2000
• SDLC - Step #5 - Documentation of the System and Design Process Posted: September 17, 2000

Link to Chapter 5.

This page was designed by John Studach. Last updated on December 29, 2000

You can send e-mail to Me.

Return to the page with my dissertation page, or my papers.