Dissertation - Appendices

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

APPENDIX I

THE SDLC RAW DATA

The data that follows refers to SDLC steps 1 - 5 in Chapter IV - the process of designing the system. The product of the process is a health promotion informatic system. The project is the designing of one. A truncated or condensed version of the raw data from the SDLC design process is included below. The full version of all of the data is available online at http://www.american.edu/academic.depts/cas/health/nchf/pubmydissertation.html..An online version of the Volere Requirements process that was used to supplement the SDLC is available at http://www.atlsysguild.com/GuildSite/Robs/Template.html.

SDLC Step # 1 - Identification of the Problem, Opportunities, and Objectives

This section calls for an analysis of the problem, opportunities, and objectives for the system.

The Problem

The two worldviews of the problem

The outcomes problem - 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.

The process problem - defined as how to best design a system that will operate optimally, efficiently, and effectively.

Six categories of process-related problems (non-prioritized)

Design - inadequacies, incompatibilities, and limitations of design theories and models and cross-domain, transdisciplinary, and intradisciplinary questions.
Development - project and team management issues and software design issues.
Data management and informatics - data integrity, flow, and management, data optimization, user interface and control concepts and overall design issues.
Technology - issues related to computer science, information technology, and telecommunications domain including software, hardware, and security concerns.
Research - theory, study integrity and designs, quantification and replication of results, and exploration of future research topics.
Business and evaluation - management, marketing, and economic issues.

The Opportunities

The opportunities that may benefit the four stakeholder groups (non-prioritized):

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.

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 healthcare arena.
To foster more efficient expenditure of resources.
To explore the pilot testing of new delivery and business models.

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.

Researchers

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

The Objectives

The Mission - the stated mission for developing the 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. Since the system will not be built as part of this study, the objectives have been reformulated as goals (non-prioritized):

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

SDLC Step #2 - Determining the System Requirements

This is the truncated or condensed version of the data that was gathered in the system requirement stage. The full version is online at http://www.american.edu/academic.depts/cas/health/nchf/pubmydissertation.html.

The raw data from the 27-step requirements process are presented below. The following is a non-prioritized synthesis of eight fundamental requirements that emerged from the requirements definition process.

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 system transactions within the system. The rights and permissions to use the data and information must conform to the appropriate laws and jurisdictions and be 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.
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.
Because the process of highly-effective long-term behavioral change is founded on the concepts of stage-related processes, goal-directed behavior, individualized decision support systems, the tailoring of content and services, and the provision of ongoing support, 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 data and knowledge bases.
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.
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.
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.
Because of the importance of providing continuum of care for promoting optimal wellness and a high quality of life, the value of 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.
Because of the complexity, sophistication, and task requirements of object-oriented system design, 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.

Supporting Diagrams

The root URL for the diagrams is http://www.american.edu/academic.depts/cas/health/nchf

followed by the exact location for the images given.

Figure 2. The Work Context - /images/figure2.jpg
Figure 3. The Context Flow - /images/figure3.jpg
Figure 4. Scope of the Project - /images/fugure4.jpg
Figure 5. Entity-Relationship Diagram - /images/figure5.jpg
Figure 6. Entity-Relationship Diagram #2 - /images//figure6.jpg

SDLC Step #3 - System Needs

Introduction to the Needs Analysis

The goal of step 3 in the SDLC process was to arrive at a recommended set of specifications for the technical and functional needs of the proposed system. This study followed the traditional practice of analyzing and then comparing the technical and functional characteristics and needs of several highly rated systems with the proposed system. The systems were ranked according to their fit with the system requirements that were established in SDLC step #2 and their value for two stakeholder groups.

The system needs are the specifications for the technical and functional requirements that satisfy the eight requirements criteria that were established in SDLC step #2. Those requirements are deemed necessary in order to address the problems that were identified in Chapter I and step #1 of the SDLC process.

The Needs Analysis

Three types of information systems were chosen for the needs analysis. The three types of systems represent a diverse set of approaches to addressing the needs of the consumer as well as very different levels of technology complexity and integration. The first type of system, Internet websites, is the most popular and most basic type of information system. The websites dispense information and offer a diverse set of services and options to consumers. The highest volume websites among these sites are the commercial sites, the biggest of which have recently evolved into "web portals". Three web portals were chosen for the comparison exercise. The web portals were chosen on the basis of their ratings for volume of web traffic per month. In the summer of 2000, three of the most popular and respected health-related websites were Mayo, Healtheon/WebMd, and Yahoo.

The second group of systems is primarily theory-based and non-profit research projects. Each of the three systems received notoriety for their work in the field of heath informatics. The three systems that were chosen were the OneLife from the American Heart Association, CHESS from the University of Wisconsin-Madison, and HealthMedia from the University of Michigan.

The final option under consideration was the advanced informatic system that is being designed though this study. This system is of the same genre as the Guardian Angel project from the group from MIT and the Health Informatics Initiative from the Koop Foundation.

The researcher carefully analyzed the features and options available through each of the three types of systems. The systems were evaluated on how well they met the eight requirement criteria that were established in SDLC step #2. The eight requirement types are; legal and ethical (consent, privacy, and security), harm prevention and error reduction, data and knowledge bases (proactivity, tailoring, and best practices), user centric (dynamic and intelligent), linking affiliated systems, data, and system elements, open systems environment, efficiency of care and communication among agents of care, affiliated systems, and evidence based, and meets the objectives of the system.

The researcher assigned a rating for functional ability (specifications about what the must system do) and technical capacity (specifications for what the system is technically capable of) for each of the systems. For functional ability, the systems were rated on a 1-5 scale on how well the system met the eight criteria. The criteria for the scale was 1=any or some, 2=low, 3=medium, 4=high, 5=exemplary. A 0-3 scale was used for the technical capacity measures. The criteria for the scale was 0= not met, 1= very basic 2=some or medium, 3=high. Ratings were given the "benefit of doubt" or rounded up when a score could have been argued either way. Scores were given for two stakeholder groups, the consumers and users (cons.) and the practitioners and agents of care (pract.) on how well the system could addressed their needs. The scores for each of the systems were tabulated, averaged, and summarized in Tables 8 and 9.

Needs Analysis - Functional requirements of the system (what it must do vs. how it does it)

The functional requirements of the system are the specifications about what the system needs to do in order to satisfy the uses of the system. The functional requirements for the system emerged from the first two steps of the system development process including outlining the problem, opportunities, mission and goals and the definition of the system requirements.

Several of the most important functional requirements for the system were established. The system must be able:

To empower users by allowing them to control their relationship to the system, control access to and use of their data, and be afforded levels of privacy, security, and confidentiality that are consistent with their wishes;
To promote health-enhancing lifestyles among users by providing proactive tailored content and services to the users;
To promote linkages, efficient communication, and illicit feedback among users and the agents and entities of care who are part of the healthcare supply chain;
To promote efficiency and streamlining through a fully integrated healthcare supply chain;
To be universally accessible;
To adapt to the diversity of the users and stakeholder groups;
To service multiple stakeholder groups;
To the best extent possible allow low barrier and tailored interfaces, multiple technology windows, channels, medium, and tools on the basis of the skill level, preferences, and tastes of each user;
To the greatest extent possible prevent harm to the system user and eliminate data and system-related errors;
To enable data from multiple formats and storage systems to be accessed, managed, and exchanged across distributed networks and systems;
To feature the best and evidence-based practices of the health domain and the behavioral and informatic sciences; and
To enable agent and intelligent technologies to perform duties for users, entities, and the system.

The data in Table 9 provides a comparison and summary of the three types of systems. The table illustrates how well the three system options would be able to meet the needs of the users and stakeholder groups.

Needs Analysis - Technical requirements (specifications for the system is capable of)

The technical requirements of the system refer to details the about the capacity and system-related design and engineering specifications that are needed in order for the system to perform at a level that satisfies the users of the system. The technical requirements are based on the functional requirements of the system. Industry standards, engineering and performance specifications, and technical requirements have been developed for most of the well-established or mature technology-related aspects within the information systems domain.

The technical requirements listed below are based on the functional requirements of the system and they reflect the consensus or standards of the industry. The system must be designed:

To conform to standards, protocols, and procedures that will maintain the highest standards of security, privacy, and confidentiality;
To support full interoperability in an open systems environment and to be flexible enough to change, migrate, or upgraded dynamically and seamlessly when appropriate;
To conform to the standard programming conventions for portable and interoperable code, source, and language environments;
To enable data to be accessed queried, managed, and stored in common or universal formats including distributed relational and object-oriented databases;

Table 9. Needs Analysis - Performance Ratings for Functional Ability

System Type Ideal Research systems (AHA, CHESS, Healthmedia) Commercial portals (Mayo, Healtheon/WebMD, Yahoo)

Requirement Type Cons Pract. Cons Avg. Pract. Avg. Cons Avg. Pract. Avg.

Legal and ethical (consent, privacy, and security) 5 5 4,5,4 4.33 3,3,2 2.66 3,3,2 2.66 2,2,1 1.66

Harm prevention and error reduction 5 5 3,3,2 2.66 3,3,2 2.66 2,3,2 1.66 2,2,1 1.66

Data and knowledgebases (proactivity, tailoring, and best practices) 5 5 4,1,4 3 3,3,3 3 1,1,1 1 1,1,1 1

User centric (dynamic and intelligent) 5 5 2,1,2 1.66 2,2,2 2 2,2,2 2 1,1,1 1

Linking affiliated systems, data, and system elements 5 5 2,1,1 1.33 3,2,1 2 1,1,1 1 2,2,1 1.66

Open systems environment 5 5 4,3,3 3.33 3,2,2 2.33 3,3,2 2.66 3,3,2 2.66

Efficiency of care and communication among agents of care, affiliated systems, and evidence based 5 5 4,3,2 3 4,3,2 3 1,1,1 1 2,2,1 1.66

Meets the objectives of the system 5 5 3,3,3 3 3,2,2 2.33 2,2,2 2 2,2,1 1.66

Average-all requirements 5 5 2.78 2.49 1.75 1.62

Key: 1=any or some, 2=low, 3=medium, 4=high, 5=exemplary.

To enable systems, devices, and appliances to communicate and interoperate across a common infrastructure that can accommodate multiple systems and platforms;
To conform to common user interfaces standards and guidelines that are flexible enough to accommodate to diverse groups of users and to adapt to the dynamic preferences and tastes of users;
To comply with standards that support the use of dynamic, mobile, and intelligent agent technologies;
To meet standards that allow for streamlining and the reengineering of the workflow and process throughout the healthcare supply chain;
To promote the linkage and communication among affiliated systems throughout the healthcare network; and
To fulfill or exceed the performance standards that are set by the designers and required by users of the system.
Data from the needs analysis for the three systems will be used to help refine the technical needs and specifications for the model system. The data will also be used by the decision makers to determine which of the systems options is most appropriate and viable.

Decision Analysis for the Recommended System

An important part of step #3 of the SDLC process is decision analysis. Several methods for making evaluations about the systems under consideration were used including the comparative analysis that is presented in Tables 5, 9, and 10, and the objective planning process method suggested by Rob and Coronel and summarized in Table 11 (Rob et al, 1997). In all cases, the proposed system was the most highly rated system and it would be the one recommended to decision makers for approval and permission to proceed with the design and development process.

Table 10. Needs Analysis - Performance Ratings for Technical Capacity

System Type Ideal Research systems (AHA, CHESS, Healthmedia) Commercial portals (Mayo, Healtheon/ WebMD, Yahoo)

Requirement Type Cons Pract. .Cons Avg. Pract. Avg. Cons Avg. Pract. Avg.

Legal and ethical (consent, privacy, and security) 3 3 2,2,2 2 2,2,2 2 1,1,1 1 1,1,1 1

Harm prevention and error reduction 3 3 2,2,1 1.66 1,1,1 1 1,1,1 1 1,1,1 1

Data and knowledgebases (proactivity, tailoring, and best practices) 3 3 3,0,3 2 2,1,2 1.66 0,0,0 0 0,0,0 0

User centric (dynamic and intelligent) 3 3 1,1,1 1 1,0,1 .66 0,0,0 0 0,0,0 0

Linking affiliated systems, data, and system elements 3 3 2,1,1 1.33 2,1,1 1.33 1,1,0 .66 1,1,0 .66

Open systems environment 3 3 2,2,2 2 2,2,2 2 2,2,2 2 2,2,2 2

Efficiency of care and communication among agents of care, affiliated systems, and evidence based 3 3 2,2,2 2 2,1,1 1.33 1,1,0 .66 1,1,0 .33

Meets the objectives of the system 3 3 2,2,2 2 1,1,1 1 1,1,1 1 1,1,0 .66

Average-all requirements 3 3 1.75 1.37 .80 .63

Key: 0= not met, 1= very basic, 2=some or medium, 3=high

The data for the two needs measurements is summarized in Table 5. The ratings have been converted to common units for purposes of comparison for all of the categories.

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

Another approach to supplement the decision-making process was suggested by Rob and Coronel. The four questions posed by Rob and Coronel - should the existing system be (1) continued, (2) modified, or (3) replaced, and (4) is it feasible? were examined for each of the three alternatives. The technical and functional needs of the systems were examined as part of the objective planning process and the data have been summarized in Table 11. (http://www.american.edu/academic.depts/cas/health/nchf/pubmydissertation.html).

An interesting alternative method that is based on the work of Deeming, the analytic hierarchy process (AHP) was not used because it is beyond the scope of this investigation. In the AHP weights for the attributes for the system are assigned on the basis of the value or importance of the characteristic to the system and users. Because of the complexity and the size of investment that would be required to build the proposed system and level of risk if the system were to actually be developed and tested, use of a more advanced decision making process would be warranted.

Technical Specifications for the Proposed System

The following is a description of the most prominent elements and attributes that are needed for the proposed system. The specifications will be used to help to define the fundamental building blocks of the system that will be featured in the system design process in step #4 of the SDLC. As the proposed system has been described as a model system, all of the standards and specifications have been chosen only if they meet or exceed the highest standards for the industry. However, the exact details of the specifications and standards have not been included because that degree of detail is beyond the scope of this study.

Design

Environment - open techniques and environment that provide for compliance, portability, scalability, and interoperability in areas such as for programming, communications, networking, system management, presentation, system services, and interfaces between applications and system services (Berson, 1996 p. 18). (For more details see Open Software Foundation, IEEE, WWW Consortium, International Organization for Standardization, Corporation for Open Systems, Object Management Group, American National Standards Institute etc.).
Architecture - the structure should be modular, multilayered, N-tiered, and conforming to the seven OSI layers (For more details see ISO reference model etc.).
Object oriented - uses a design and modeling process that allows for encapsulated packages of data and functionality among the elements of complex systems.
Unified Modeling Language (ULM) is a common approach that is used. (For more details see Knapik, Gamma etc.).
Development - follow a strategic, staged, and incremental methodology and use techniques for complex systems e.g. prototyping, iterative designs etc. (Kendall, Jacko etc.).
Interface - presents a look and feel that conforms to and accommodates to the user and features elements and attributes including mulitmodal, GUI, single system image, CCOW desktop interfacing middleware (For more details see Shneiderman, Neilsen etc.).

Technical

Central structure and interfaces - all of the considerations that allow the system and its elements to interoperate, function, and perform as required.
Security - methodologies, protocols, tools, and techniques such as Secure Sockets Layer (SSL), Public Key Infrastructure (PKI), 128 byte level encryption, and electronic signatures that meets the standards of the HIPPA 1996 guidelines, HL7, WWW consortium and other standards and governing bodies (For more details see HIPPA, Netscape etc.).
Telecommunications - infrastructure that is flexible, scalable, and accommodates the full spectrum electronic and digital options including wireless (microwave, satellite, infrared, spread-spectrum), protocols (TCP/IP, SNA, and Bluetooth) voice over IP, gateways, hubs, routers, Asynchronous Transfer Method (ATM), H.32x telecommunications protocols (Mitretek Telecommunications Review etc.).
Networking - should accommodate and feature flexible and scaleable topologies including LAN's, WAN's, GAN's, etc.
Programming languages and environments - open and portable such as CORBA, JAVA, Enterprise Java Beans, ActiveX, CCOW, HL7, SNOWMED, XML etc. (For more details see Knapik, Kendall, Sun Microsystems, WWW consortium etc.).

Data

Access, control, and management - must allow for integration of all data sources, ensure the security and integrity of the data, and be able to resolve issues such as redundant and missing data, corrupt data, concurrency etc.
Rights and permissions - the system must be user-centric in that users must have control of and grant permissions for access to their data.
Administration - procedures and systems for issues such as audit trails, fault tolerance, backups, etc.

Components and Modules (the core)

Central structure - the processes, procedures, rules, and the instructions and design of how the system is structured and works, adjusts, and dynamically updates itself (to be formalized in SDLC step #6).

Devices for input and output - must accommodate a full range of options including computers, peripherals, and communications devices and appliances such as phone, wireless, PDA's, handhelds, optical scanners, electronic and auditory input etc.
Interface - accommodating, intelligent and dynamic that is user centric and allows communication among the full range of input and output devices, and is mulitmodal so that it can function in several sensory channels including speech synthesis and recognition.
Data and knowledge bases and sources - the main data sources and elements including the universal identifier, the personal data profile, lifestyle, behavior and stage, incentives and motivation databases, the support network, content warehouse communications object, domain knowledge bases, the supply chain repositories, and even some of the emerging ones including Geographical Information Systems (GIS).
Agents - software agents that perform a variety of automated tasks (SDLC #2) and that have characteristics such as mobility, intelligence, dynamicity, object orientation, as well as the ability to accommodate soft computing functionality (fuzzy logic, evolutionary, neural networks).
Service components - production and delivery of products and services, support networks, incentives and motivation.
Tailoring module - inference engines and knowledge bases for tailoring.
Affiliated systems - the supply chain including practitioners and agents, of care, healthcare providers, surveillance, tracking, and monitoring systems.
Support - help and technical support tools and systems for users of the system.

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

Summary

The goal of this step was to define the technical and functional requirements for the proposed system and conduct a comparative analysis of the merits of the proposed system relative to the other options that were evaluated. Although a direct comparison of the three types of systems is very difficult because of the major differences in the nature of the systems, given the requirements of the system as stated in step #2, the proposed system is clearly superior to the other options. Therefore, the design of the proposed system should proceed to the next step.

SDLC Step #4 - The Model System Design

The Recommended Model System Design

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 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, the 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 et al., 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 et al., 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.

The System Model

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.

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, knowledge bases, 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 is "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 the 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 1996 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 et al., 1997).

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.

The Functional and Data Requirements

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

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.

An Entity-Relationship Diagram (Figure 5) 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 the full online version of the documentation (Studach, 2000).

A second ER diagram, Figure 6, (Supporting diagrams below) presents a slightly different view of the relationship between the data, the user, the system and the system entities. The knowledge bases 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.

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.

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 in Appendix V 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.

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.

Performance

Speed, memory, bandwidth, and length of play are among the typical performance-related issues that designers must address. 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.

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 and to minimize interruptions.

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. These specifications should exceed or move the performance to a higher level with agents and object-oriented programming.

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.

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.

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.

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 1996 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 processes.

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.

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 should include 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.

Legal Requirements

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

SDLC Step #5 - The Documentation of the System and Design Process

All of the text, figures, and tables in these appendices and the online materials comprise the documentation for the model system design and design process (Studach, 2000). Additional documentation and materials will be added to the documentation and it will become part of the historical record and archive for this project.

APPENDIX II

THE SCENARIOS

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.

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.

APPENDIX III

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.

APPENDIX IV

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.

APPENDIX V

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.

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 my dissertation page or the page with more of my papers.

Last Updated: December 10, 2001