Dissertation - Appendices

Tomorrow's leaders in health promotion are being educated at American University today.

SDLC Step #4 - The Model System Design

Note: this page corresponds to the SDLC analysis and it leads to the final product in the Appendices. The numbering sequence here follows the Volere analysis, however, the numbering pattern has changed in the final document.

This page is divded up into major two sections. The first section, In a nutshell, is a bulleted listing and summary of the major points for this step. A complete presentation of the data for this step is featured in the second section.

In a nutshell

The Core Concepts

The first step in the modeling process began with a restatement of the core concepts. All of the work for this model design is founded on the system mission and goals as stated in SDLC step #1. Among the objectives that were derived from the mission and goals are improved health and quality of life, empowerment of consumers, reductions of the health-related burden and economic costs for individuals and society, increased efficiency within the healthcare system, and advancement of the next generation of health-enhancing technologies.

The Stakeholders

The second step in the design process called for naming the stakeholders who will be part of the system and impacted by it. The key stakeholders can be grouped in several ways including individuals, consumers and users, practitioners and agents of care, affiliated systems of the healthcare supply chain, providers and sponsors, developers, researchers, and policy makers. The value of the system for individuals and organizations and the business-related forces in the environment generally emanate from or are related to one or more of these stakeholder groups. It is vitally important that designers understand who they are trying to serve and please and why.

The Scope of Work and System Boundaries

The third step in the design process focused on defining the scope of work for the system. The 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 way to give readers a perspective of the system model and the elements is through a context diagram. The main system elements and the flow and context of the processes are represented in Figure 3, the Context Flow Diagram.

Several points are worth highlighting in this diagram. Some parts of the system entities have been diagramed in groupings because of common functionality. The first point to make about the diagram is that the main focus of the system is the relationship between the system and the users. Second, the system has an array of databases that provide and serve as repositories for all forms of data that the system needs to function and accomplish the goals in an optimal manner. Third, the system has a full spectrum of entities that make up the healthcare supply chain that is connected to the system. Collectively the family of knowledge bases, the fourth group of entities, provides enormous amounts of knowledge that the system continually draws on to ensure it is using the best practices from each of the domains. The fifth group is the family of agents that continually perform functions for the benefit of the system and users. Sixth, the system has many users and the primary mission of the system is to provide content and services for the users. The system is linked to an array of practitioners and agents of care, some of whom work directly or indirectly with or for users of the system.

The Object-Oriented Design

At this point in the design process, it became evident to the researcher that with the scope, complexity, level of sophistication, as well as the number and types of components, modules, and technologies it would be virtually impossible, even for a designer who is well versed in all aspects of the system, to depict the entire system in a clear, meaningful, and comprehendible fashion in a linear two-dimensional representation on paper. Given that one of the conclusions of SDLC step #3 was to use object-oriented design principles, and following the advise of design experts such as Knapik, Gamma, and Giarratano it was decided that developing a scenario would be a very productive and feasible way of moving forward with the design process.

The Event List and Scenario

As a fifth step, a generic scenario with a set of 20 events that might be encountered during a typical cycle was developed. An event list, with a description of probable inputs, outputs, and entities that might be involved, was generated for the scenario in SDLC step #2. The event list was particularly useful for describing and tracking the flow of data and processes, as well as the relationships among the system components and elements. The scenario and event list (Figure 2) were used and will be referred to throughout the design process.

The Scope of the Product

A Use Case Diagram (Figure 4) was produced for the sixth step in the design process. The Use Case Diagram when combined with the basic concepts of the system with the event list helped to define the scope of the product (the health promotion informatic system). The Use Case Diagram was used to illustrate the elements and entities of the system and how they function and interrelate.

See below for more details.

SDLC Step 4 - The Model System Design

IV. The Recommended Model System Design

A. Introduction to the Design Process

In the previous steps the SDLC process the tasks were related to defining the problem, opportunities, and goals, the system requirements and needs, deciding whether the system that is envisioned for this project offers greater potential and value for the consumers and stakeholders than the other options currently available, and on answering the question about whether is the cost and risk is worth the anticipated return. The goal of this step is to design the system and to present the reader with a clear picture of what the system looks like, its' parts, how it is structured, and how it might operate. The system will be described with narrative descriptions, illustrations, and examples such as scenarios.

Several traditional ways are used to describe and illustrate an information system. Two approaches from Stair, narratives and schematic diagrams, will be used to describe the system (Stair, 1996). Logical models are presented to illustrate, form the user perspective, how the system is organized and how the components interrelate. Kendall mentions data-flow, entity-relationship, and context diagrams as useful tools that help individuals to understand the system (Kendall, 1999). Knapik states that scenarios are particularly useful for describing systems that are highly complex and sophisticated, that are widely distributed, and that feature novel or "fuzzy" designs (Knapik, 1997). Each of these modeling methods will be employed in this step.

Generally, the second part of the SDLC step #4 continues on with the actual development and implementation of the system. However, since this is a design study the development part of the process is beyond the scope of this investigation.

B. The System Model

1. The core concepts

The first step in the modeling process began with a restatement of the core concepts. All of the work for this model design is founded on the system mission and goals as stated in SDLC step #1. Among the objectives that were derived from the mission and goals are improved health and quality of life, empowerment of consumers, reductions of the health-related burden and economic costs for individuals and society, increased efficiency within the healthcare system, and advancement of the next generation of health-enhancing technologies.

2. The stakeholders

3. The Scope of Work and system boundaries

The third step in the design process focused on defining the scope of work for the system. The Work Context Diagram (Diagram 7a) was particularly useful for illustrating the system boundaries and the relationships among the key entities of the system.

4. The context flow

Several points are worth highlighting in this diagram. Some parts of the system entities have been diagramed in groupings because of common functionality. The first point to make about the diagram is that the main focus of the system is the relationship between the system and the users. Second, 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. Third, the system has a full spectrum of entities what make up the healthcare supply chain that is connected to the system. Collectively the family of knowledgebases, the fourth group of entities, provides enormous amounts of knowledge that the system continually draws on to ensure it is using the best practices from each of the domains. The fifth group is the family of agents that continually perform functions for benefit of the system and users. Sixth, the system has many users and the primary mission of the system to provide content and services for the users. The system is linked to an array of practitioners and agents of care, some of whom work directly or indirectly with or for users of the system.

5. The object-oriented design

At this point in the design process, it became evident to the researcher that with the scope, complexity, level of sophistication, as well as the number and types of components, modules, and technologies it would be virtually impossible, even for a designer who is well versed in all aspects of the system, to depict the entire system in a clear, meaningful, and comprehendible fashion in a linear two-dimensional representation on paper. Given that one of the conclusions of SDLC step #3 was to use object-oriented design principles, and following the advise of design experts such as Knapik, Gamma, and Giarratano it was decided that developing a scenario would be a very productive and feasible way of moving forward with the design process.

6. The event list and scenario

As a fifth step, a generic scenario with a set of 20 events that might be encountered during a typical cycle was developed. An event list, with a description of probable inputs, outputs, and entities that might be involved, was generated for the scenario in SDLC step #2. The event list was particularly useful for describing and tracking the flow of data and processes, as well as the relationships among the system components and elements. The scenario and event list (Table 7a) were used and will be referred to throughout the design process.

7. The scope of the product

A use case diagram (Diagram 8a) was produced for the sixth step in the design process. The use case diagram when combined the basic concepts of the system with the event list helped to define the scope of the product (the health promotion informatic system). The use case diagram was used to illustrate the elements and entities of the system and how they function and interrelate.

Several important points that are illustrated in the use case diagram and are worth highlighting. First, there are two human entities represented in the system, the consumers and users and the practitioners and agents of care. The consumers and users are the direct targets of the system, whereas the practitioners and agents of care ideally are indirectly but, intimately involved and integrated into the change process.

Second, because of the number, complexity, and interrelationship of the elements of the system there is a strong rationale for representing those entities that share common attributes and characteristics as system objects. Likewise, the various types of data have been represented as system databases, knowledgebases, or warehouses. Encapsulated in each of the objects is a methodology that allows them to communicate, collaborate on tasks, and exchange data within the constraints that are established by the system protocols.

Third, all of the system elements, objects, and databases are serviced by software agents that execute a variety of tasks for the benefit of the user or the system as a whole. Although there is a great deal of diversity in agents, they generally possess multiple characteristics. For example, they are typically self-directed, able to communicate, conform to security protocols, can learn and demonstrate intelligence, and may be mobile, dynamic and distributed.

Fourth, the first system event "create_master_record" and "create_unique_ID" for each consumer or potential user of the system. The success of the system is predicated on the ability of the system to customize itself and tailor the content and services to the unique preferences and tastes of each individual. The quality, and therefore effectiveness, of tailoring is heavily dependent on the completeness, accuracy, currency, and the ability of the system to capture, store, and deliver strategically important data elements. By using the unique ID, all of the data-related elements of the system can be linked. Moreover, by using tailoring data and concepts, every element in the system can be synchronized and matched so that the efficiency of the system can be optimized and the experiences of the users of the system can be as pleasurable as possible.

Fifth, a unique aspect of the system is embodied in the first three steps in the event list. In the first step, a master record and unique ID is generated for every potential user of the system. The second event on the list reveals that a set of agents continuously execute system procedure calls that are designed to reduce all types of system and data errors and to minimize the potential for harm to any user. The third event in the triad is related to guidelines for consent, permissions, and security.

The system is founded on three principles. The user must initially consent to interact with the system and must always be allowed to be in control of their contact with the system. According to the principles of a democratic society and the HIPPA guidelines users have the right to control and grant access to their data. Finally, the system must continually work to enforce stipulated or acceptable levels of security for all transactions and system interactions. Therefore, if an individual declines to interact with or be part of the system, although a master record is maintained and the system always works to optimize itself, no services will be provided directly to the user.

The sixth point worth highlighting is that because of the object-oriented structure of the databases and the master record and unique ID, the system is able to track and assess the impact of users, events, transactions, and interactions among the system modules, components and entities, and within the limits of practicality, intelligence, and performance use the data for the maximum effectiveness.

Finally, it is worth noting that the event list was set up to illustrate one linear unidimensional scenario. The researcher has experimented with the event list using the scenario in a variety of sequences and configurations. However, because of all of the possible permutations in the event list, other possible events, and a host of unpredictable factors it is possible to play out the event case list in an endless set of combinations and scenarios. This offers an excellent opportunity for developers and researcher to run simulations and invoke evolutionary computing concepts to explore the system model in great detail (Gold, 1998, Knapik, 1997).

8. The fit criterion

In step 8.b of the Volere process requirements model, the event list was used to define actors and fit criterion for the scenario. Plausible and measurable fit criterion were established for each of the 20 events. Although performance criterion are vitally important to the system design, development, implementation, and evaluation of process, no further examination of them will take place because of the nature of this design study.

9. The functional and data requirements

a. Functional elements

The functional and data requirements of the system were defined in step 9 of the Volere requirements process. The event list was used as a framework for examining the rational for each of the requirements of the system that were associated with the 20 events and the anticipated degree of user satisfaction or dissatisfaction that might be associated with how well the requirements were met by the system. The researcher used a mixed-methodology approach to predict the how strong or weak the reaction would be given the goals of the system. The elements that had the strongest ratings were marked as high priority elements in the system.

b. Data elements

The use case diagram (Diagram 8a)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.
An entity-relationship diagram (Diagram 9b) was constructed to illustrate the major functional relationships of the data for the system and user side of the model for a service and content scenario. The cardinality of the relationships was determined by the elements that were the most likely to be prominent given this scenario. Fit criterion for the attributes of the data elements were established and presented in Table 9b.

A second ER diagram (Diagram 9d) presents a slightly different view of the relationship between the data, the user, the system and the system entities. The knowledgebases and agents have been loosely grouped because of common functionality. The diagram also shows that there are six significant sets of data associated with each user in this system design.

9. 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. 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 a reluctance to explore and exploit the full functionality of the system.

The discussion points below relate to the front end or interfacing features as well as the aspects of the back end functionality that comprise the product qualities of the system. In this section of the system design process, the use of tailoring or customizing the system to the unique preferences and tastes of the user is of primary importance. Therefore, in this area is the part of the system design process the art of design is often more important than the science.

a. The look, feel, and style

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 the user instead of forcing a user to adjust to the system. Moreover, it should change seamlessly and dynamically as the 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, 1998). This is accomplished through the flexible design and architecture, determining user preferences, proactively monitoring use patterns, continually collecting and probing data streams, and tasking the agents do the work. In short, the system should appear highly attractive to all users and no user should be left behind.

A set computer screen snapshots have been included below to illustrate how the interface can be customized to the preferences of a diverse set of users. The construction and presentation of the screens are developed through a series of user interface analysis techniques such as focus groups, laboratory usability testing, and monitoring use patters in real time.

b. Usability and ease of learning and use

The principle of low or no barrier holds true for usability and ease of learning 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 user 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 lower level devices and interfaces may be familiar to most of the population such as a telephone, TV, or radio. Others devices may require 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. Examples of learning tools include built-in help, wizards, tutorials, assistant agents, on-line help, training classes, and special interest or support groups.

c. Performance

Speed, memory, bandwidth, and length of play are among the typical 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 can do much of that work.

d. Safety

There are few safety issues that are related to the users of the system. Proper advanced warning and instruction can minimize most of the safety concerns. The agents and knowledge bases will proactively work to reduce the level of risk users are exposed to.

e. Precision

The system must take into account the accuracy concerns of the users. Users should expect near zero tolerance for faults and high levels of precision and accuracy from the system. Many systems use routine fault and error-checking mechanisms to address the precision needs of the system and the users.

f. Capacity

Massive amounts of data will reside on the array of data and knowledgebases 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.

g. Operating environment

The system must be able to operate in any environment. The number of options plus the flexibility and modularity of the design, structure and interface should prevent any limitations of use or access.

h. Maintainability and portability

As was stated in the requirements section, one of the key features of the design is the dynamic nature of the system. A premium must be placed on the ease of replacement and compatibility of the parts of the system. Some parts of the system will be replaced or upgraded on an established schedule, while others are made seamlessly, often without knowledge of the users.

i. Security, confidentiality, file integrity, and audit requirements

Most parts of the system that contain personal data are either restricted or confidential. Permission may only be granted explicitly by the users, or implicitly through certain entities or surrogates in the healthcare supply chain to others that should have access to the data and information. Multiple levels of access and security are defined. Many of those types of restrictions have been stipulated in the new HIPPA guidelines.

The integrity of data can greatly influence the effectiveness, quality, and value of the care that is available to the users of the system. Therefore, it is important that a premium be placed on gathering, storing, and distributing only data that is clean and cross-checked whenever possible. Checking systems should be placed at the entry points for the data and at other strategic points in the system.

Protocols and procedures must be in place to check, validate, and edit data in the system. Audit checks should be performed at several strategic stages.

j. Cultural and political requirements

Although the system is removed from most political considerations, non-the-less it must conform to the policies of the government and organizations when it is under the purview or jurisdiction of those bodies. The system includes mechanisms that enable it to be aware of and adaptable to newly enacted rules and regulations as they arise.

The multi-cultural makeup of the population in the United States dictates that the perspective of all peoples should be accommodated by the system. The system will build on the strengths of this diversity.

k. Legal requirements

The system will comply with all laws and ethical standards within the United States.

C. The content and services

The remainder of this section will focus on descriptions and illustrations of the types of content and services that will be provided by one or more modules of the system.

In the table below six typical user scenarios are provided to illustrate how health promotion concepts might be operationalized within the conceptual framework of the system design. The objectives are offered as examples of how some generic themes might be played out and to specify some circumstances where the system might be effective. The products and components columns contain information about how the system might satisfy the objectives for the scenarios and which system elements might be most prominent in the process. A system-wide objective that is inherent in each case is to establish, fortify, or nurture the link or relationship between the user and the system.

The Scenarios

A pregnant/postpartum mother - 1. To build on her instincts and desire to have a healthy child (promotion/prevention), 2. To strengthen the maternal bond (emotional/spiritual), 3. To prepare for reversing the effects of pregnancy (physical/psychological), and 4. To establish a solid connection link with healthcare providers (follow-up care/periodic triggers/efficiency).
New Year's resolution for an individual - 1. To 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. To establish a start date and realistic goals for a behavioral improvement program (goal setting/skill development), and 3. To establish a customized and targeted program regime for change (programming/motivational).
A sports physical for a teenager - 1. To provide routine screening services (assessment/prevention), 2. To capture, monitor, and update physiological and other data that are collected from the screening tests and history (data collection/benchmarking), 3. To use the opportunity and eagerness of the participants to offer or link them into other services (links with affiliated systems/motivational), and 4. To 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. To promote compliance with follow-up services and treatment regimes (compliance/prevention), 2. To activate and strengthen bonds with support networks (support/emotional), and 3. To provide opportunities for mentoring and community support (community/environmental).
A young adult with family history - 1. To 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. To promote use of routine screenings (screening/compliance), 3. To 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. To promote lifestyle changes that can mediate the effects of genetic predisposition when possible (behavior change).
An adult conducting an Internet search - 1. To promote empowerment among users (empowerment), 2. To secure permissions and capture preferences and use pattern data that can be used to build a personal profile (permissions/data gathering), and 3. To generate interest and provide an entertainment for users that will encourage repeat visits to the site or use of the services (promotional/psychological).

Table 12. The Scenarios - System Functionality and Health Promotion Concepts

Scenario Products or services System components

Pregnant/ postpartum mother (objectives: 1. a healthy child, 2. mother/ family bonding, 3. physical reconditioning, 4. caregiver linkages) User record (create id/ record and link with the mother). Monitor and enforcing (minimize errors and harm). Programming (tailored maternal services and a reconditioning regime). Compliance enhancements (triggers and monitoring). Networking (support from other mothers and specialists). Master record. Error/ fault checking. Tailored products and services. Knowledge and databases and communication module. Support networks and affiliated systems.

New Year's resolutions for an individual (objectives: 1. assessment, 2. goal setting 3. program/ regime/ skill development, and compliance) Assessment/ benchmarking and profile development (tracking). Motivation (behavioral triggers and cues). Programming (skill development and regimes). Master record, personal profile, and lifestyle database. Incentives and motivation and reminder agents. Tailored products and services.

Sports physical for a teen (objectives: 1. assessment/ prevention, 2. benchmarking/ collection 3. motivation, 4. performance enhancement) Screening (periodic monitoring/ tracking). Incentives system and compliance (goal attainment). Programming (skill and knowledge development for strengthening and athletic programs). Master ID, personal profile, and knowledge base. Motivation and incentives and support networks. Tailored products and services.

Breast cancer survivor (objectives: 1. compliance/ prevention, 2. support/ emotional, 3. community) Tracking/ screening (monitoring/benchmarking). Support (personal emotional support) Motivation (contributing to support community). Master ID, personal profile, harm reduction, and knowledge bases. Motivation and support. Communication, support, and affiliated systems.

Young adult with family history (objectives: 1. education, 2. screening/ compliance, 3. data/ records, 4. behavior change) Information and education (knowledge). Compliance (tracking). Behavior change (skill development). Knowledge bases and content. Incentives and motivation. Tailored products and services.

Adult conducting an Internet search (objectives: 1. empowerment, 2. permissions/ data, 3. promotional) User-preferences (profile). Support and information (compliance and content). Incentives (motivation). Personal profile. Affiliated systems and support network. Incentives and motivation.

ATTRIBUTES OF EXEMPLARY SYSTEMS

Several authorities in the field suggested that one of the best ways for the researcher try to become immersed in the subject area and understand the trends, issues, barriers, and characteristics of the products in the market place was to conduct a search and if possible use the best products available. To that end, the researcher began a process of identifying a set of "exemplary systems" that were either proposed, under development, or fully operational.

The first step in the process was to identify a set of exemplary systems. An extensive search of the health-related product market place was conducted in order to identify the best-of-the-breed of exemplary systems. The search techniques included interviews with experts and developers in the field, checking the presenters, topics, issues, and exhibitors at conferences, tracking articles, notices, and advertisements in the health informatics magazines and professional journals, scans of the literature, Internet searches, and checking for award-winning products and systems. Among the most fruitful resources included the 1996 United States General Accounting Office report titled Consumer Health Informatics: Emerging Issues, the United States Department of Health and Human Services Partnerships conferences from 1997-2000, the 1997 Interactive Healthcare 97 conference, the Lexant conference titled The Art of Seeing Things Once Invisible, and articles and advertisements from issues of Healthcare Informatics and MD Computing.

The second step in the process was to try to arrange a test of all or modules, parts, or elements of the system that were operational. Actual product testing of many of the systems was possible at the exhibit halls at conferences or over the Internet. The products ranged from highly futuristic or conceptual designs, to research and theory-based systems, as well as commercial products.

The third step in the process was to try to develop a list of characteristics that could be used to compare the systems. An extensive list of attributes that corresponded to the full array of dimensions from the systems was developed. The list was pared down to a short list of key attributes. Many of the characteristics that made the final list were selected because of the common functionality across the systems as well as for their comparability with the features of proposed system that was evolving throughout the SDLC process.

In discussions with experts in the field, interviews with and focus groups of users, and readings of literature on in the subject area, several key features began to emerge as important considerations. A set of shortcomings, disadvantages, and barriers were identified. These features and the attributes of the framework from the attributes and traditional/generic vs. advanced technologies Tables 3 and 4 in Chapter I were arranged into a table format. The discussions also included projections about possible time horizons for the adoption scenarios. The time horizons are very dependent on the level of complexity of the task, sense of organizational commitment, and the resources available.

The final step in the process was to select a set of five products for comparison. The final list contains four theory and research-based systems and one conceptual system. It was determined that because of the relative inadequacies of the systems no commercial products were sufficiently advanced to make the final list of exemplary systems. In Table 7, the features that make the system stand out and some of the shortcomings in the system when compared to the model system.

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

Adoption, Implementation, and Validation Questions

The following are a set of questions that were posed by the Committee that are related to adoption, implementation, and validation of the conceptual framework and the model system design. The questions are arranged in a sequence that is indented to provide and lead to answer about alternative paths to adoption. This data becomes part of the historical data for the Volere Requirements Process and the system documentation.

1. What could people really do with this design and what are some of the barriers to adoption?

The purpose of this dissertation was to arrive at a design for an innovative health promoting informatic system. The system design was conceptualized with a projected time horizon for full-scale operation several years into the future. However, it is reasonable to assume that either the basic structure and functionality of the full system could be operational within a three-year time span or for entities that are more risk averse or who have limited resources or other constraints one of several viable alternatives methods of development could be explored.

Because of the nature of this study, the researcher worked through the design process in an environment free of restraints or real world limitations. However, there are obviously many serious potential real-world limitations such as: the difficulties of securing the long-term and proactive commitment, leadership, and support from the most senior level decision makers; the forces related to the project development, implementation, and maintenance costs; the availability of individual and organizational expertise and manpower to design, develop, deploy, and maintain the system; issues related to securing cooperation among all affiliated entities along the healthcare supply chain; the availability of and access to mature and stable technologies described in the design; the factors related to the acceptance and penetration of technologies among the target and key user populations; the aspects related to cultural change and adoption among users who are linked directly or indirectly to the system; the acceptance of and training for practitioners and agents of care who would be linked into the system; and the development or enactment of practical legal standards and public policies that would enable the full functionality of such a system.

Clearly, there are a number of major factors and barriers that would prove to be insurmountable for all scenarios except for the best-of-the-best situations. Therefore, a more practical role for this design is to serve as a conceptual framework that reflects a best-case scenario. Consequently, the design should be looked at in terms of relative suitability for a particular organization, consortium, or group of entities rather than as an absolute standard that must be adopted "all or none".

2. Is this the only path to development or adoption?

No, several viable alternative methods are available to developers, organizations, or consortia that might be interested in taking this system design and concepts toward the process of development, implementation, or validation.

3. What are the alternative paths?

On a continuum of adoption, five traditional paths to adoption are: (1) wholesale adoption (develop the entire system as designed, all at once); (2) rapid prototyping (attempt to develop the whole system, but in a staged piece-by-piece approach); (3) incremental (a planned staged process of development and adoption of parts of the whole concept or by strategically selecting sets of the modules to build); (4) evolutionary (work toward the adoption or incorporation of some or all of the parts of the system as the forces and drivers of the environment dictate or seem appropriate); and (5) wait/do nothing/outsource (don't do anything on your own and if appropriate try to take what others develop as it becomes available, or look for superior systems and approaches).

4. What are the characteristics of the approaches e.g. barriers, time horizons, constraints, advantages, disadvantages, factors/aspects cost, risk etc.?

In general, for each of the options: the closer the strategy is to the model system the more and greater the overall risk and constraints; the less the total time until adoption and penetration of a critical mass; the more intensive the initial training required; the greater the requirements for cultural change that will be required for it to function optimally; the shorter the time horizon until there is full adoption; and the greater the probability of achieving the objectives in the most efficient way possible. Conversely, the more removed the alternative strategy is from the model: the less overall risk, constraints, and demand for immediate dedication of resources and training at one time; the longer the adoption time, the less radical and rapid cultural change is required; and the farther away from the optimal efficiency and achievement in terms the proposed system goals and objectives.

5. What are the implications of the approaches?

The relationship between the risk to return or need to capabilities for the proposed system and the alternatives could be expressed in mathematical terms. A set of equations could be used to illustrate the inverse relationship between the relative risk and the projected reward for each of the options presented above. However, a complete analysis of them is beyond the scope of this study. Yet, many experts have stressed the importance of following a careful planned process of analysis and decision making in order to arrive at the best scenario for each situation. Ultimately and ideally, the option that is chosen should be tailored to the unique mix of strengths, weaknesses, opportunities, and threats for each organization. The advantages, disadvantages, constraints, and key factors for each entity must be carefully weighed. Decision makers must evaluate the relative value of the choices for the present as well as the potential or projected future cost and benefits for their organization or constituency. A few of the considerations will be portrayed in the scenarios below.

6. What does this mean and what are the implications to the profession(s)?

There are a host of implications associated with the adoption or movement toward this conceptual framework or model. Each of the factors could have a profound impact on the users, health promotion professionals and agents of care, and organizations and entities that would be part of the system. First, the users must be aware of and knowledgeable about the capabilities of the system. All of the stakeholders must develop an accurate sense of the potential of and how a technology-based system could work.

In the future it will be important that those in the healthcare side of the system play an active or proactive role in the systems analysis and design process or by participating on design and development teams. Alternatively, healthcare processionals can be involved indirectly by researching or keeping abreast of the latest trends or by participating in surveys, focus groups, or usability testing of systems during the development or evaluation phases. Another important strategy is viewing IT systems from a systems perspective and looking at the problems, issues, treatment and outcomes of current programs, and interventions that they produce. Other key roles for health practitioners include seeking, training, and planning or leading culture change, and reassessing the role of practitioners with an expanded scope of reach and responsibilities, and contributing to the knowledge engineering process.

7. How do we get the word out and diffuse the results?

There are a host of channels and opportunities for the dissemination of the results and concepts of this study such as:

Trade and academic journals,
Presentations, tutorials, workshops, and posters at conferences,
Exhibiting at conferences and trade shows,
Seeking the chance to and giving interviews to media,
Postings to list-serves, newsgroups, and electronic bulletin boards,
Posting information on Websites, and links to like-minded sites,
Development of training programs through academic institutions, and
Working with professional organizations and committees.

8. How can alternative methods of adoption be explored though the scenarios?

The scenarios below are useful for illustrating examples of the analysis process for different methods of systems development. The analysis will begin with an exploration of the relationship between need and capacity for potential developers of the system. This exercise can be part of an analysis that could lead into stepped adoption approach. The entities listed form a diverse group of typical organizations that will be used for this analysis process exercise.

A. A multinational Fortune 100 company (largest size and private).

B. A branch of the military service (largest size and public).

C. A multisite regional public health agency (medium sized, public, and healthcare).

D. A high-tech regional company/franchise (medium sized, private, and tech).

E. A multisite outpatient clinic in one small community (smallest size, public, and healthcare).

F. A single-campus private university (smallest size and private).

Other examples of entities that could be used as scenarios include: a large foundation (e.g. Robert Wood Johnson, Pew Charitable Foundation, Koop Foundation, and the California Welfare Foundation), a large non-profit or cluster of them (e.g. the American Heart Association and the American Cancer Society), a Governmental agency or cluster of them (e.g. the Department of Health and Human Services HHS, CDC, Social Security, Medicare, AHCPR, NIH etc.), a local health club or chain of them (e.g. Gold's Gym and Ballys), and a large insurance company or HMO (e.g. Blue Cross/Blue Shield, Kaiser Permante, Metropolitan Life etc.)

The eight requirements in the table are from the requirements definition process. For this exercise a sample rating has been assigned for each entity based on how important the requirement might be to them. This data shows that there is considerable variability among the entities with respect to need. The two health entities have the greatest need (6.5,6.5) and the three private entities have the lowest (3.9,4.5,4.8).

For this exercise ratings were assigned to each entity based on how well it might be prepared to provide for the system needs as stated on p. 119 - 122. This data shows that there is considerable variability among the entities as summarized in Table 13. The size of the entity (7.9,7.2,5.9) is the most important factor in assessing the capacity of the entity as shown in Table 14. The level of technology penetration within the entity is the second most important factor. The health entities are among the lowest in capacity (4.4,5.2).

Table 13. Assessing the Organizational Need

Requirement Fortune Military Reg. PH HiTech Clinic Univ

Ethical/legal 7 8 9 7 9 7

Error/harm 5 5 7 5 8 5

Data/knowledge base 4 4 5 3 6 3

User-centric 2 2 2 3 2 2

Affiliated systems 4 7 7 3 7 2

Open systems 6 8 7 8 6 5

Efficiency and communication 6 8 8 5 8 4

System objectives 2 3 7 4 6 3

Total-average/agg. 36=4.5 -5 45=5.6 -3 52=6.5 -2 38=4.8 -4 52=6.5 -1 31=3.9 -6

For this exercise an aggregate need/capacity value was calculated for each entity. The comparative ranking for the score is given in each column. This data shows that the military (6.8) and regional health entities (6.1) might be the most likely targets for more rapid development and adoption, while the private university (3.8) might be the least likely because the score is so much lower than the others.

Table 14. Assessing the Organizational Capacity

Core components and modules Fortune Military Reg. PH HiTech Clinic Univ.

Central structure 9 9 6 9 4 5

Devices 8 9 5 7 4 4

Interface 8 9 4 8 2 3

Data 8 9 5 7 4 3

Agents 5 6 3 4 2 3

Services and products 8 8 6 5 5 5

Tailoring 7 7 7 4 5 4

Affiliated systems 6 8 8 4 7 3

Support 5 6 7 5 8 4

Total- average/agg. 64=7.2 -2 71=7.9 -1 51=5.7 -4 53=5.9 -3 40=4.4 -5 33=3.7 -6

The ratings for several groupings of the entities were calculated for this portion of the exercise. The top three scores for each entity were used. The comparative ranking for the score is given. This data shows that the health sector has the highest need (6.5) , but is among the least prepared (5.7) the terms of capacity. The larger institutions (7.6) are among the most capable by a considerable margin, but they have relatively lower levels of need (5.1) as defined by the system goals and objectives.

Table 15. The Organizational Need/Capacity

Organization Need (Rank) Capacity (Rank) Aggregate (Rank)

A Fortune 100 4.5 - 5 7.2 - 2 11.7 = 5.85 - 3

B Military 5.6 - 3 7.9 - 1 13.5 = 6.8 - 1

C Regional Pub Health 6.5 - 1 5.7 - 4 12.2 = 6.1 -2

D HiTech 4.8 - 4 5.9 - 3 10.7 = 5.4 - 5

E Local Clinic 6.5 - 1 4.4 - 5 10.9 = 5.5 - 4

F Private University 3.9 - 6 3.7 - 6 7.6 = 3.8 - 6

By engaging in an analysis exercise of this type, it is possible to begin to tease out which of the different of methodologies might be most appropriate for each of the entities. It is very possible that different criterion might be substituted in the initial analysis phase. Another technique that assigns a weighted value to the criteria that have higher levels of relative worth is a worthwhile approach to consider when working through the decision making process.

Table 16. Need and Capacity Ratings by Type of Entity

Type Need Capacity Need (Rank) Capacity (Rank)

Public (B, C, E) 5.6,6.5,6.5 7.9,5.7,4.4 18.6 = 6.2 - 2 18.0 = 6.0 - 2

Private (A, D, F) 4.5,4.8,3.9 7.2,5.9,3.7 13.2 = 4.4 - 6 16.8 = 5.6 - 4

Large (A, B) 4.5,5.6 7.2,7.9 10.1 =5.1 - 5 15.1 = 7.6 - 1

Medium (C, D) 6.5,4.8 5.7,5.9 11.3 = 5.7 - 3 11.6 = 5.8 - 3

Small (E, F) 6.5,3.9 4.4,3.7 10.4 = 5.2 - 4 8.1 = 4.1 - 6

Health (C, E) 6.5,6.5 5.7,4.4 13.0 = 6.5 - 1 10.1 = 5.1 - 5

Using the ratings data from Tables 13 - 16 above, the are the key aspects for the preferred adoption path for the healthcare entities (C & D).

Highest needs - ethics/legal (9, 9), efficiency of communication (8,8), error harm reduction (8,7) = 49
Highest capacity - affiliated systems (8,7), support networks (8,7), tailoring (7,5) = 42
Lowest needs - user-centric (4,4), data/knowledge bases (5,6), open systems (7,6) = 32
Lowest capacity - agents (3,2), interfaces (4,2), linking devices (5,4) = 15
Therefore given the mission of the healthcare entities the following recommendations for design of any system are offered.
Focus on the core goals of health ministering to patients/changing behavior.
The following are the needs that are related to the core goals: system objectives, error/harm, ethical/legal, efficiency and communication, and affiliated systems currently one of those (affiliated systems) were identified as strengths in Table 12.
That goal (core mission/central structure) should receive a number one priority and the other three (central structure, data, affiliated systems) should be enhanced by an incremental approach because of the IT issues and the cultural traditions of the organization.
Tailoring and enhancement of service is something that could be developed through rapid prototyping. However, this task is probably only feasible for the larger of the two entities. The tailoring and enhancement of services could compliment the development in the other related areas.
Components such as data and devices are within the resources and capabilities of the health entities, however they would be best achieved by an evolutionary means.
The agents and interface components should adopt a do nothing/wait/outsource approach.

This figure graphically represents the differences in need and capacity for the six organizations from the scenarios. The data to plot the points comes from the summary data contained in Table 15. It illustrates and reinforces the point that different paths to adoption should be selected and matched to each entity.

Figure 7. Scatter Plot of Adoption Paths for Six Entities Based on Their Need-to-Capacity Ratio

Table 17 illustrates a suggested set of alternative paths for adoption for each of the components from the model system design for a regional public health agency. The recommendations about which paths to use were based on the need-to-capacity data from Tables 13 - 15. For this analysis the array of databases (DB) and knowledge bases (KB) have been considered separately for some entities when appropriate.

Table 17. Alternative Adoption Paths for a Regional Public Health Agency

Component Wholesale Prototyping Incremental Evolutionary Do Nothing

Central structure #1 Reg. PH,

Array of devices Reg. PH

User-centric interface Reg. PH

Data and (DB) knowledge bases (KB) Reg. PH (DB) Reg. PH (KB)

Intelligent agents Reg. PH

Service components Reg. PH

Tailoring module Reg. PH

Affiliated systems Reg. PH

Support network Reg. PH

Some of the main advantages and disadvantages to adoption are summarized in Table 18. A rough time horizon for each of the paths to adoption is included in the first column.

Table 8 illustrates a suggested set of alternative paths for adoption for each of the components of the model system for and all six of the scenarios. The decision about which paths to use were based on the need-to-capacity data from Tables 13 - 15. For this analysis the array of databases (DB) and knowledge bases (KB) have been considered separately for some entities when appropriate.

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).

Table 18. Advantages and Disadvantages of Alternative Paths to Adoption

Paths to adoption Advantages Disadvantages

Wholesale adoption Time to adoption: (1-3 years) The whole system is up and running early and functioning as an entire unit. There are clearly defined and shared goals.The testing and debugging of all of the components is easier. It is beyond the capabilities and resources of almost all single entities. It may be difficult to pull together so many of the pieces simultaneously. It may be difficult to manage such a large and complex project.

Rapid prototyping Time to adoption: (3 months ¦ 5 years) It is a proven methodology. There is a defined path to adoption. There is a built-in feedback mechanism. It is resource intensive. It may take longer. Coordination and management of project segments can be difficult.

Incremental adoption (planned/staged) Time to adoption: (6 months ¦ decade) The path is more acceptable to a greater number of people. It may be easier to fit within the scope of available resources.There is less demand for rapid cultural change in the organization. The path may miss out on some of the key elements and the synergistic effect. It takes a long time to get to the full system. There may be considerable redundancy during the adoption phases.

Evolutionary process to current models/ approaches (as it comes) Time to adoption: (decades or never) It follows the natural course as technologies and models progress. It is an easier adoption path and is less threatening to established cultures. There is less need for intensive dedication of resources. It is a slow path to change. The process may be haphazard. The sequence and need of some of the key elements may be missed. It takes much longer to realize the full benefits of the systemic changes.

Do nothing/wait/ outsource Time to adoption: (varies greatly) There is no or little cost for waiting. Outsourcing is easier on overall organizational resources. Onsite development expertise is not needed. There may be substantial lost opportunity costs. Outsourced products often lead to in-house cultural problems. Long-term technical support may be an issue.

TAILORED SCREEN SHOTS

An interactive version of the tailored screen shots, Figure 8, is available online at http://www.american.edu/academic.depts/cas/health/nchf/pubmydissertation.html. The screen shots will be used to illustrate the various types of interactivity, user interfaces, and behavioral change options.

On to SDLC 5 - Determining the requirements for the proposed system

This page was designed by John Studach and is maintained by the NCHF webmaster. Last updated on December 29, 2000.

You can send e-mail to Me.

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

Last Updated: December 10, 2001