Dissertation - Appendices

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

Updated: December 28, 2000

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 three sections. The first section, In a nutshell, is a non-prioritized list of the requrrements. The second section is an expanded but condensed bulleted listing and summary of the major points for step of the SDLC. A complete presentation of the data for this step is featured in the final section.

Determining the System Requirements

In a nutshell

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

SDLC STEP 2 - Determining the System Requirements

This section follows the Volere Requirements Specification Model

1. The purpose of the system - to improve the health status and quality of life of Americans by influencing the health behaviors, habits and lifestyle choices of the users of the system.

The goals of the system are as follows:

To empower consumers;
To network the affiliated systems and agents of care and to link them into the systems process of care;
To embed effective dynamic state-of-the-art advanced informatic technologies in the system;
To base the system on the best and evidence-based practices of the behavioral and informatic sciences;
To design the system with an array of services that is based on a model of optimal wellness and lifelong care;
To work 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; and
To learn about what is possible and practical from the development and implementation of the next generation of health-enhancing systems.

2. . The client - customer and stakeholders

Individuals/users/consumers - ratings of user satisfaction, access and use patterns, stage of change for lifestyle-related health behaviors, quality of life ratings, ratings of support networks, general health status ratings, compliance measures,
Practitioners and agents of the healthcare system ratings of user satisfaction, levels of use and access patterns for the system, quality and quantify of interactions among patients, other practitioners, and entities in the system, individual and aggregate access data for healthcare system resources, productivity measures, assessments of knowledgebase, compliance measures to protocols and guidelines,
Providers and sponsors - ratings of satisfaction with system, productivity measures, ROI/cost-benefit analysis,
Developers - ratings of satisfaction of purchasers of system, units of products sold, revenue streams generated by spin-off products, new applications, processes developed and tested,
Researchers - qualitative and quantitative testing
Policy Makers - ratings of constituent satisfaction, return on investment,

3. The Constraints - There are several types of constraints that are related to the system design.

Conceptual constraints and boundaries have been imposed by system designer (e.g. user-centric approach and control, universal access, end-to-end serviceability, the emphasis on security, privacy, and confidentiality etc.)
Technological limitations and constraints are inherent in the types of current and future technologies that might be part of the final system.
There are a number of legislative and policy issues, as well as ethical, and legal considerations.
A host of constraints are related to the stakeholders, agents, and entities that are part of the healthcare value chain.
The goal of this project is to design a model system, therefore it is not possible to test the model and make appropriate adjustments.
Many of the business, financial, implementation, and development issues and complexities, have been designated as beyond the scope of this study.

4. The assumptions that the team are making about the project

The primary assumption is that the design could be developed and it will work within the context of the mission and goals that were set for the system.
Closely related to the core assumption is that the characteristics of the envisioned system (i.e. proactive, intelligent, dynamic, consentant requirement, secure, open etc.) should be the highest priority for the system.
Consumers and individuals would use the system if it were available to them.
Agents and healthcare entities would agree to become part of the health value chain.
Adequate safeguards could be built into the system to prevent undue harm or violation of personal privacy.
Policy and legislative requirements would not prevent or circumvent key aspects of the system.
Developers will continue to maintain, enhance, review, and adjust the system over time.
The array of technologies can be made to work together.
Competent teams could be assembled to develop, deploy, and support the system.
Funders would be willing to devote sufficient resources to develop, install, maintain, and improve the system for the long term.

5. The core concepts

Note: This section containts the whole thing - a working draft of all of the data for the definition of the requirements for the system. This section follows the Volere Requirements Specification Model. The data from this step will be synthesized, condensed, and folded into section 2 of the SDLC process in Chapter 4. Each section and subsection begins with a short description of the notes from the Volere Requirements Specification Model.

SDLC Step 2 - The Requirements

The product is a Health Promotion Informatic System

PRODUCT DRIVERS

1. The purpose of the product

1a. The user problem or background to the project effort.

a. Content (A short description of the work context and the situation that triggered the development effort. It should also describe the work that the user wants to do with the delivered product.)

There are a tremendous number of opportunities for infusion of advanced technologies throughout the healthcare arena. The health promotion informatic system is conceptualized as a comprehensive health promoting informatic system that is based health promotion principles and the best and evidence-based practices of the behavioral and informatic sciences. The system will featuring the integration of intelligent state-of-the-art technologies for the purpose of promoting health-enhancing lifestyle choices.

b. Motivation (Without this statement, the project lacks justification and direction.)

Currently, there is a great deal of excess suffering, uncoordinated and inefficient use of healthcare resources, and an enormous economic burden on individuals, organizations, and society. Much of the burden is directly attributable to lifestyle-related health behaviors and choices of individuals and the lack of use of advanced informatic systems that can be alleviate these problems. At this time, comprehensive health promoting information systems that are based on the best science do not exist in the marketplace.

The direct goals for the system are to promote, influence, and support empowered users through proactive techniques that are designed for improvements in individual health status, movement toward an optimal state of well-being, and improved quality of life. This is accomplished by creating comprehensive health-enhancing environments through informatic systems that can influence and support positive health habits and lifestyle-related behaviors and decisions.

Indirect benefits will come in the form of strong mutually reinforcing support networks, reductions in the incidence and severity of disease and illness, through a general contribution to the reengineering of the healthcare systems, by economic benefits for individual, organizations, and society, and through the learning that comes from the infusion and proliferation of advanced informatic systems and pushing the envelope of technology in the healthcare arena.

c. Considerations (You should consider whether or not the user problem is serious, and whether and why it needs to be solved.)

Although the level of waste, and the incidence of excess illness and death has been well documented, in an open-market and democratic society, not everyone is amenable to being part of systems that use proactive techniques to influence their behaviors. On the day-to-day basis many individuals are satisfied with or complacent about the status of their health. Moreover, relatively few are motivated, ready, or willing enough, or able to make changes.

There are many driving forces for these systems. There are many benefits that could accrue for individuals, organizations and the healthcare system by the development and implementation of advanced health promotion informatic systems. However, tradeoffs such as feelings of invasion of privacy, security of health information, harmful health-related decisions by empowered individuals, user and practitioner acceptance of these tools, the unknowns and downsides of technology, and the competition for scare resources for these initially capital-intensive systems are among the considerations that must be factored into the decision-making process.

1b. Goals of the product.

Content (This boils down to one or at most a few, sentences that say, "What do we want this product for?" In other words, the real reasons that the product is being developed.)

The system must be comprehensive, efficient, effective, and optimized for each individual and capable of influencing the lifestyle-related health decisions, behaviors, and habits in a health-enhancing direction. It must be technologically feasible, be accepted and used by consumers and practitioners, produce enhancements in health status and quality of life, and generate positive economic returns.

Motivation (There is a real danger of this purpose getting lost along the way. As the development effort heats up, and the customer and developers discover more and more what is possible, it may well be that the system as it is being constructed wanders away from the original goals. This is a bad thing unless there is some deliberate act by the client to change the goals. It may be necessary to appoint a person to be "custodian of the goals", but it is probably sufficient to make the goals public, and periodically remind the developers of it. It should be mandatory to acknowledge the goals at every review session.)

The goals that are listed in no particular order of priority for the system are as follows:

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

Fit Criterion (An objective measure that will enable testing to determine if the goal has been met by the product.)

The first set of performance criterion is related to the outcome measures. As this is a design study no actual performance data would be available. However some of the measurable outcomes data for the various stakeholders are listed in the next section.

The second set of performance objectives for the process outcomes is related to the systems design process. The process objectives that are listed below do not include the deliverables related to the actual implementation, and evaluation iterations of the SDLC cycle. Among the factors from the first 5 stages that are to be assessed are:

Were all of the steps of the design process completed?
Were the deliverables for the process produced?
Was the process completed in a timely manner?
Did the system design evolve as conceptualized and specified?
Was the system documentation produced?
Were the recipients of the design satisfied with the end product?.

2. Client, customer and stakeholders

Individuals/users/consumers - ratings of user satisfaction, access and use patterns, stage of change for lifestyle-related health behaviors, quality of life ratings, ratings of support networks, general health status ratings, compliance measures, utilization of resources
Practitioners and agents of the healthcare system- ratings of user satisfaction, levels of use and access patterns for the system, quality and quantify of interactions among patients, other practitioners, and entities in the system, individual and aggregate access data for healthcare system resources productivity measures, assessments of knowledgebase, compliance measures to protocols and guidelines
Providers and sponsors - ratings of satisfaction with system, productivity measures, ROI/cost-benefit analysis
Developers - ratings of satisfaction of purchasers of system, units of products sold, revenue streams generated by spin-off products, new applications, processes developed and tested
Researchers - qualitative and quantitative testing.
Policy Makers - ratings of constituent satisfaction, return on investment, compliance with laws

3. Users of product

Since the system is designed as an end-to-end system, all entities along the healthcare supply chain are users of the system. At the individual level the consumers and users are the most direct users of the system. Many other levels of the healthcare supply chain are users directly or indirectly.

PRODUCT CONSTRAINTS

4. Mandated constraints

There are several types of constraints that are related to the system design.

Conceptual constraints and boundaries have been imposed by system designer (e.g. user-centric approach and control, universal access, end-to-end serviceability, the emphasis on security, privacy, and confidentiality etc.)
Technological limitations and constraints are inherent in the types of current and future technologies that might be part of the final system.
There are a number of legislative and policy issues, as well as ethical and legal considerations.
A host of constraints are related to the stakeholders, agents, and entities that are part of the healthcare value chain.
The goal of this project is to design a model system, therefore it is not possible to test the model and make appropriate adjustments.
Many of the business, financial, implementation, and development issues and complexities, have been designated as beyond the scope of this study.

5. Naming conventions and definitions - Dictionary of terms and acronyms, used in the project - definitions (This dictionary should build on the standard names that your organization, or industry, uses. The names should also reflect the terminology in current use within the work area)

Because of the scope, degree of sophistication, and advanced nature of the system that is envisioned there are a host of definitions and conventions that are related to this study. The following are relevant terms:

Stakeholders (see subsection 2 above)

Consumers and users - those who access or consume health-related resources
Practitioners and agents - health and medical professionals
Providers and sponsors - organizations or entities (or individuals) who produce, supply, deliver, care or sponsor healthcare services to users or consumers
Developers - those who design, develop, and deploy products and services directly to consumers or through providers or agents
Researchers - individuals or organizations that evaluate the process or effect of programs
Policy makers - individuals and organizations who legislate and enforce health-related policies

Healthcare

Health Promotion - O'Donnell, Downey, Fyfe, and Tannahill
Health Status - Healthy People 2000
Quality of Life - Healthy People 2000
Wellness - Karch
Health Insurance Portability and Accountability Act (HIPPA) of 1996 - standards for security, privacy, and accountability
Healthcare supply chain - all health-related agents and entities involved in aspects of the development, supply, delivery, and support of healthcare programs, products, and services.
Evidence-based practice - Cochrane, AHCPR

Health Informatics

HL7 - standards for healthcare developed through the W3.org
CCOW -
Electronic Medical/Health Record - all of the data related to health of an individual stored in an electronic or digital format - (variations include client, patient )
Telehealth - remote services though technology (telemedicine is a subset)
AMIA - American Medical Informatics Association professional, policy, and advocacy organization
GIS/GPS - geographical information systems
CDC - surveillance systems
Uniform Medical Language (UMLS) - SNOWMED,

Behavioral Science

Theories and models - Transtheoretical model /Stage of Change Prochaska, Decision theory, Crisis Theory,
Motivation -
Psychographics - characteristics and attributes about an individual or population group

Informatics

Informatics - The art and science of the informatic sciences
Interface - Shneiderman - AMIA
Usability testing - AMIA conference
Best practices - literature
User-centric vs. system centric - the system makes adjustments and accommodations to the user vs. the user making accommodations to the system.
Exemplary attributes and characteristics - seamless, fully-integrated,
Business Process Reengineering (BPR) - Hammer
Systems approach - Weinberg

Technology - including standards

Object-Oriented - Gamma, Girratano, Knapik
Object - is an encapsulated package of functionality and data -all of the attributes of the data and all of the routines and methods associated with it (Knapnik, p. 52/3).
Agent - a software entity that carries out a set of operations and that possess operational characteristics of autonomy, social ability, reactivity and proactivity (Knapik p. 2/3)
Object Agent - elements of the system that possess the attributes of an object and the operational characteristics of the software agents (Knapik p. 76/7)
Artificial Intelligence and software agents - Knapik, Turing, Girratano
Open source - Stallings, Torvalds,
Telecommunications standards - TCP/IP,
Security - PKI, encryption, biometric technology
Wireless - technologies, devices, and standards
Technology windows - any digital or electronic device through which the user can interact with the system. PDA's (personal digital assistant)
Smart-cards - a technology whereby data and information can be stored or accessed through a..
Data - (may be a sub category) data, modeling, mining, knowledgebase, inference engine,
Online analysis and processing - (OLAP) - real-time transaction processing
Time - real-time, store and forward, synchronous, asynchronous,
JAVA - platform-independent programming language
Applications and products - simulations, robotics, remote sensing, agents,
IEEE - International Electrical and Electronic Engineers - standards and policy making organization
Next- generation technologies -
Protocols/standards (this may be a separate category)
XML - extensible markup language

Design and methodology

Design study - define, specifications, plan, design, and document but not develop or implement
SDLC - seven step methodology (Kendall & Kendall) without build, test, review and evaluate
Volere - process and methodology for engineering and systems design - Robertson
Modules, components, elements -
Prototyping - taking subsets and developing - design sources
Architecture - layers infrastructure

6. Relevant facts and assumptions

6a.External factors that have an effect on the product, but are not mandated requirements constraints.

Content

Many of the healthcare issues are very complex and interrelated. It is difficult to isolate many of the forces and drivers. Some of the significant factors are:

Social and cultural drivers such as consumerism and empowerment are among the most powerful set of forces are related to sociological changes.
Healthcare, business, and market environment that is rapidly changing.
Information and telecommunications technology and the rapid convergence, diffusion, advancements, and the impact and dynamic nature the technology sectors across multiple domains.
Access to and diffusion of computer-related technologies.
Critical mass of users of technology-related products and services.
Workforce and recreational users that are more skills, savvy, and that are expecting and demanding improvements and new advancements in technology.
Global changes and forces do have an impact on healthcare and technology.

Motivation

The mantra of technology, faster, better, cheaper applies across the board. Among the motivating factors are the drive for cost savings and for improved performance, productivity, reduced errors, enhanced customer satisfaction, and improved market share.

6b. Assumptions that the team are making about the project

Content

That the primary assumption is that the design could be developed and it will work within the context of the mission and goals that were set for the system.
Closely related to the core assumption is that the characteristics of the envisioned system (i.e. proactive, intelligent, dynamic, consentant requirement, secure, open etc.) should be the highest priority for the system.
That consumers and individuals would use the system if it were available to them.
That agents and healthcare entities would agree to become part of the health value chain.
That adequate safeguards could be built into the system to prevent undue harm or violation of personal privacy.
That policy and legislative requirements would not prevent or circumvent key aspects of the system.
That developers will continue to maintain, enhance, review, and adjust the system over time.
That the array of technologies can be made to work together.
That competent teams could be assembled to develop, deploy, and support the system.
That ultimately, funders would be willing to devote sufficient resources to develop, install, maintain, and improve the system for the long term.

Motivation

That the team is able to anticipate the barriers and roadblocks to success, plan accordingly, and ensure that all players are on "the same page".

Considerations

Alternatives and options must be available and clearly researched in the event that major changes or redirections are necessary.

FUNCTIONAL REQUIREMENTS

7. Scope of work

7a. The context of the work.

The following are the named elements of the system. The system is designed to promote lifestyle behavior changes. The affiliated systems interact with the system continually to provide the necessary data, information, and knowledge and to promote dynamic optimization of the performance and capacity of the system.

For diagram 7a - the Work Context Diagram click on this link The Work Context Diagram

The diagram has two main parts. The components of the affiliated systems will be developed further below.

1. The system ~ .0 - Lifestyle Behavior Change Work Context

2. The affiliated systems

System fundamental principles - basis of the system design.
Data array - all forms of data and array of databases (e.g. personal health record, personal preferences profile, psychographic data, surveillance and monitoring, community profiles etc.)
Practitioner and agents - agents and entities that provide programs and services to the individual.
Provider chain - serve as agents or sponsoring entities that provide programs and services for the individual or groups.
Personal support networks - provide general and specific support for behavior change programs.
Technology domain - domain of infrastructure, interfaces tools, windows, techniques, and applications etc.
Policy and legislation - provide resources and develop guidelines, laws, regulations, and restrictions etc.
Developers - initial and ongoing development, support and enhancements for the system.
Health-related environment - positive and negative influences.
Informatic sciences - best practices of the domain.
Behavior sciences knowledgebases - best practices of the domain.
Health and medical evidence-based practices - best practices of the domain.

7b. Work partitioning

Content

An event list, identifying all the business events to which the work responds. The business events are user-defined. The response to each event represents a portion of work that contributes to the total functionality of the work.

The event list - from the Scope of work (diagram 7a) and corresponding to the product boundary diagram (8a) and the use-case scenario list (8b)

Table 7a - The Event List

Event name Input & Output

7a1. Verify/create new user record Execute a birth or new user procedure call. (in)

7a 2. Invoke error/fault check agent Monitor error event protocols and use/adhere to fault checking guidelines. (internal)

7a 3. Verity/create consent and permissions Execute a new or updating consent and permissions procedure call. (internal)

7a 4. Create/update affiliated system linkages Execute a procedure call for an environmental scan to create/update all of the linkages among affiliated systems and the healthcare supply chain. (out)

7a 5. Invoke technology agent for user-centric interface and tools Invoke technology agent to ensure user-centricity, optimization, and tailoring of experiences for user sessions. (internal)

7a 6. Update/create user profile Perform the procedure call for the system to update the user profile. (internal)

7a 7. Update/record granted/denied consent and permissions Execute the procedure call to check the most current permissions data profile then grant or deny access. (internal)

7a 8. Update user profile linkages Update the user profile internally and to the affiliated system linkages. (out)

7a 9. Update/create benchmark/track for lifestyle/behavior/stage The system executes a procedure call that queries the user record and for benchmarks and tracking of lifestyle, behavior, and stage of change. (internal)

7a 10. Check/update practitioner notes or indices of progress The system performs a procedure that checks and updates the practitioners and agents of care notes and for indices of progress. (in)

7a 11. Intelligent agent query of domain data and knowledgebases An intelligent agent initiates an internal check of all of the relevant domain area data and knowledgebases and updates the system for each scenario. (internal)

7a 12. Agent - dynamic system updates An agent checks knowledgebases and affiliated systems and performs a dynamic update of all system elements. (in)

7a 13. Activate/create alert or cue to action if warranted An alert agent in the system provides alerts and cues to action to the user based on the data and protocol from best practices knowledgebases. (internal)

7a 14. Generate tailored content and services The system generates tailored content and services for the user. (internal)

7a 15. Deliver services to user A delivery agent in the system delivers the services to the user in the most appropriate fashion. (internal)

7a 16. Probe for user feedback An agent for the communications/feedback object initiates a procedure call for feedback from the user. (internal)

7a 17. Record feedback from the user and internal system update The communications/feedback object records the feedback from user and communicates with internal elements. (internal)

7a 18. Activate motivation loop The system performs a check for motivation profile and dispenses incentives if appropriate. (internal)

7a 19. Activate support network if appropriate An agent checks and dispenses support if appropriate. (out)

7a 20. Generate follow-up tailored content and services. The system provides ipsitive follow-up content and services that are tailored to the user. (internal)

Note: in=input from other systems out=output for other systems internal=intrasystem

The event list is a partial representation of the full chain of events for a particular use-case scenario. Many cyclical and iterative subroutines may be invoked for as a result of any of the procedure calls that are identified in the event list. Although a thorough definition of all of the potential events and their relationships are beyond the scope of this view of the system, this scenario is useful for illustrating the types of responses and sequences that the system may engage in.

8. Scope of the project

8a Product Boundary

The use case diagram identifies boundaries between the users and product. The product boundaries for a use case scenario from step 7a have been summarized in diagram 8a. For diagram 8a - the Scope of the Project Diagram click on this link - Scope of the Product

8b Use case list

The use case diagram is a graphical way of summarizing all the use cases relevant to the product.

The use case list table below is a subset of a more complete descriptive table for the scenarios in Table 7b. The use case list summarizes the user/actor, description, fit criterion and system-related scenarios that are related to Table 7b.

Table 8b. - Use Case List

ID # Use/actor name Description Fit criterion Scenarios

8b.1 The system Execute a verify or new user procedure call Verify/create one record for each potential user for each required event System-initiated procedure call upon notification of a birth, registration of a newly sponsored user, or an open enrollment request for verity/create a record by event such as 7a.1 and 4.

8b.2 Agent object - error/fault checking Monitor error event protocols and use/adhere to fault checking guidelines. Enforce all error/fault check protocols for each required event Agent-object initiated error/fault checking routine caused by an event such as 7.a.1, 3, 4, 5, 7, 12 etc.

8b.3 Agent object - consent, permissions, and security Execute a new or update consent, permissions, and security procedure call. Verify/create consent, permissions, and security initially, update periodically, and always enforce system rules in downstream processes Agent-object initiated verify/create procedure call for consent, permissions, and security routine caused by an event such as 7.a.1, 4, 6, 7, 9, 10, 12 etc.

8b.4 System object - the healthcare supply chain Execute a procedure call for an environmental scan to create/update all of the linkages among affiliated systems and the healthcare supply chain. Update/create new all existing linkages according to system protocols and schedules Object initiated create/update routine of affiliated healthcare entities for an event such as 7.a.1, 2, 3, 6, 10, 12, 13 etc.

8b.5 System object - technology/intelligent agents Invoke technology agent to ensure user-centricity, optimization, and tailoring of experiences for user sessions. Check for technology/agent advancements periodically and update system according to system protocols and schedules Object initiated technology/intelligent agent routine for user-centric interfaces and tools from an event such as 7.a.1, 2, 3, 4, 6, 10, 12, 14, 16 etc.

8b.6 Database agents - user personal profile Perform the procedure call for the system to verify or create the user personal profile. Verify/create a profile for each new user, update when changes occur, and probe for changes periodically according to system protocols and schedules Database agent initiated update/create user profile procedure call for an event such as 7.a.1, 2, 3, 4, 5, 7, 9, 10, 12, 17, 18 etc.

8b.7 Agent object - consent, permissions, and security Execute the procedure call to check the most current consent, permissions, and security data profile then grant or deny access. Update and record consent, permissions, and security when changes occur and according to system protocols and schedules Agent-object initiated update granted/denied consent, permissions, and security routine for an event such as 7.a.1, 2, 3, 4, 5, 7, 9, 10, 12, 17, 19 etc.

8b.8 Database agents - user personal profile Update the user profile internally and to the affiliated system linkages. Update personal profile linkages according to system protocols and schedules Database agent initiated update routine for user profile linkages for personal profile data from an event such as 7.a.6, 10, 12, 17, 19 etc.

8b.9 Database agents - lifestyle, behavior, and stage of change The system executes a procedure call that queries the user record and for benchmarks and tracking of lifestyle, behavior, and stage of change measures. Update lifestyle, behavior, and stage of change measures for selected behaviors for all users when changes occur and create benchmark measures for all new users and targeted behaviors according to system protocols and schedules Database agent initiated benchmark/track routine for lifestyle/behavior/stage of change data from an event such as 7.a.1, 4, 7, 10 12, 14, 17, 18 etc.

8b.10 Agent - practitioners/agents of care The system performs a procedure that checks and updates the practitioners and agents of care notes and for indices of progress. Update/check notes portfolio and strategic indices with practitioners and agents of care and update according to system protocols and schedules Agent initiated update/check routine for practitioners and agents of care from an event such as 7.a.1, 2, 4, 6, 8, 9, 11, 13, 14, 17, 19 etc.

8b.11 Knowledgebase and data agent - health, behavioral, and informatic sciences An intelligent agent initiates an internal check of all of the relevant domain area data and knowledgebases. Query domain data and knowledgebases for best practices according to system protocols and schedules Knowledgebase and data agent query routine of domain knowledgebases from an event such as 7.a.4, 5, 9, 10, 14, 18 etc.

8b.12 Update agent - knowledgebases and affiliated systems An agent checks knowledgebases and affiliated systems and performs a dynamic update of all system elements. Update domain data and knowledgebases periodically according to system protocols and schedules Update agent procedure call for dynamic system updates from an event such as 7.a.4, 5, 11 etc.

8b.13 Database agent - motivation and incentives An alert agent in the system provides alerts and cues to action to the user based on the data and protocol from the domain knowledgebases. Activate/create alerts and cue to action for all system users according to system protocols and knowledgebases Database agent initiated activate/create routine for alert/cue to action from an event such as 7.a.1, 2, 3, 4, 5, 6, 9, 10, 12, 14, 16, 20 etc.

8b.14 Production agents - content The system provides tailored content and services for the user. Generate content and services according for all system protocols and knowledgebase criterion Production agent initiated procedure call for generating tailored contend and services from an event such as 7.a.4, 9, 10, 12, 13, 17, 18, 19 etc.

8b.15 Delivery agents - to user A delivery agent in the system delivers the services to the user in the most appropriate fashion. Deliver required services for each service-related event according to system protocols and schedules Delivery agent initiated procedure call for delivery of tailored services to users from an event such as 7.a.9, 13, 14, 17, 18, 19, 20 etc.

8b.16 Agent object - communication and feedback An agent for the communications/feedback object initiates a procedure call for feedback from the user. Probe for user feedback based on system protocol and service event schedules Agent-object initiated probe routine for feedback from users from an event such as 7.a.3, 5, 6, 9, 10, 13, 15, 18, 19, 20 etc.

8b.17 Agent object - communication and feedback The communications/feedback agent records the feedback from the user and communicates with all of the systems internal elements. Record each element of user or system internal feedback and update all appropriate internal system linkages Agent-object initiated record feedback routine for communication from users and the system from an event such as 7.a.1, 2, 3, 4, 6, 9, 10, 12, 16, 18, 19 etc.

8b.18 Database agent - motivation and incentives The system performs a check for the users motivation profile and dispenses incentives if appropriate. Activate motivation and incentives loop according to system protocol and appropriate event sequences Database-agent initiated procedure call for motivation and incentives loop from an event such as 7.a.1, 2, 3, 4, 6, 8, 9, 10, 12, 13, 14, 16, 19 etc.

8b.19 Database agent - support network An agent checks and dispenses support if appropriate. Activate support network according to system protocol and appropriate event sequences Database-agent initiated procedure call for support network from an event such as 7.a.1, 2, 3, 4, 6, 8, 9, 10, 12, 13, 14, 16, 20 etc.

8b.20 Production agents - content The system provides ipsitive follow-up content that is tailored to the user. Generate follow-up content and services according to system protocols and knowledgebase criterion Production-agent initiated procedure call for follow-up services for users from an event such as 7.a.10, 11, 13, 15, 17, 18, 19 etc.

Table 8c - The Use Case Scenario Cross-check List

In the table that follows The events that are checked below are not used during the scenario described in 7b.

ID # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

8b.1 x x x

8b. 2 x x x x

8b. 3 x x x x

8b. 4 x x x

8b. 5 x x x

8b. 6 x x x x x

8b. 7 x x x x x x x

8b. 8 x x x x x x x x

8b. 9 x x x x x x

8b.10 x x x x x x x

8b.11 x x x x x x x x x x x x

8b.12 x

8b.13 x x x x x x x

8b.14 x x x x x x x

8b.15 x x x x x x x x

8b.16 x x x x

8b.17 x x x x x

8b.18 x x x x x x

8b.19 x x x x x

8b.20 x x x x x x

9. Functional and data requirements

9a. Functional Requirements.

Content

In a fully developed system of the type that is envisioned for this project, there are an enormous number of functional and data requirements. However, a complete description of all of them is beyond the scope of this project.

A scenario from the event list (Table 7a) was used to develop a full set of functional requirements for the data using the Volere Requirement Shell. A sample of seven of the fields that were chosen to be presented in the table below. The functional requirements serve as the basis for defining the functional and data requirements in section 9b.

Table 9a - Functional and data requirements

ID

Num
Req.Type Event/use case # Description of requirement Rationale for requirement User Satisfaction User Disisatisfaction

9a.1 9 1, 3, 4, 6, 9, 12, 15, 17 A system agent will verify/create an unique record for each (potential) user When there is a universal ID and record for each user, then it is possible for the system elements to interoperate, to link affiliated systems, and to link data relationships and streams. 5 5

9a.2 9 2-4, 6,8,9, 11-17 Agent objects will activate error/fault checking mechanisms When these agents are used, then it is possible to enable system-wide fault checking and error reduction. 5 5

9a.3 9 2-4, 6,8,9, 11-17 Agent objects will establish consent, security and permission parameters, maintain a secure record for each user, and enforce consent, security, and permission protocols When the agents are used, then the system establishes and maintains strict user-control/concentric parameters, establishes a permissions protocol infrastructure, and promotes a user-control/centric secure environment for all actions throughout the system. 5 5

9a.4 9 1-4, 6-9, 11-17 System objects will create/update linkages with all affiliated systems of the healthcare supply chain When the linkages are established, then all relevant healthcare entities are linked for end-to-end coverage and service network for all actions throughout the system. 5 5

9a.5 9 2-4, 6-16 Technology agents will find the best-of-the-breed interfaces and tools to optimize and tailor experiences and sessions for users When the best-of-the-breed interfaces and tools are used, then the system adapts to each user and each action throughout the system is an optimized, tailored, and user-centric experience. 5 5

9a.6 9 2-4, 6-16 Database agents will verify/create a personal profile for key psychographic variables for each user When the personal profiles are used, then each action and deliverable throughout the system is an optimized, tailored, and user-centric experience. 5 5

9a.7 9 1-4, 6-17 Agent objects will update/record the granted/denied rights for consent, permissions, and securit When the consents, permissions and security are maintained for each user for each session and all actions throughout the system, then the user has maximum control and security violations are minimized. 5 5

9a.8 9 2-4, 6-16 Database agents will update the personal profile for key psychographic variables for each user When the personal profiles are updated, then each action and deliverable throughout the system is an optimized, tailored, and user-centric experience. 5 5

9a.9 9 1-4, 6-9, 14-16 Database agents will update/create benchmarks/track lifestyle/behavior/stage for each targeted behavior for each user When the benchmarks and tracking are established, then each action and deliverable throughout the system can be tailored for each user. 5 5

9a.10 9 2-4, 6-9, 13-17 An agent will check/update practitioner notes or indices of progress When the practitioners and indices of change are up-to-date, then the system and practitioners can provide services optimally. 5 5

9a.11 9 2-4, 6-17 Intelligent agents will query the domain data and knowledgebases When the system elements use the state-of-the art and evidence-based practices, then it can provide the best services possible 5 5

9a.12 9 2-4, 6-17 Intelligent agents will update the domain data and knowledgebases When the system elements are up-to-date from the knowledgebase queries, then the system will use the state-of-the art, evidence-based practices, and it can provide services optimally. 5 5

9a.13 9 2-4, 6-9, 12,16 A database agent will provide alerts and cues to action according to system protocols to promote behavior change When the alert/incentives loop is activated, then the system can remind the users to act. 5 5

9a.14 9 1-4, 6-16 The system will generate content and services form the content data warehouse that is tailored for the user. When the content is tailored to each user, then the chances of behavior change are greatly improved. 5 5

9a.15 9 1-4, 6-16 Delivery agents will deliver content and services to the user in the optimal manner When the content is delivered in an optimal manner, then the chances of behavior change are greatly improved. 5 5

9a.16 9 2-4, 6-16 A feedback agent will probe the system and user for feedback When the system has feedback, then it can optimize itself for the user. 5 5

9a.17 9 2-4, 6-16 A feedback agent will record the feedback from the system and user When the system has recorded the feedback, then the feedback can be used to optimize itself for the user in future events. 5 5

9a.18 9 2-4, 6-9, 12,16 A database agent will activate the incentives/motivation loop to increase behavior change When the system uses the incentives/motivation loop, then the chances of behavior change are increased. 5 5

9a.19 9 2-4, 6-16 A database agent will activate the support network to provide support for behavior change When the system uses the support network, then the chances of the user complying with the behavior change regimes are increased. 5 5

9a.20 9 1-4, 6-16 Production agents will generate follow-up content for the users When the system generates the follow-up content and services, then the chances of the user complying with the behavior change regimes are increased. 5 5

9b. Data requirements.

Content

There are a host of data sets and types that are necessary in order to develop the type of system envisioned for this project. A data model based on the scenario from the event list (Table 7a) was constructed. The relationships among the entities have been illustrated in the ER diagram 9b.

The entity-relationship diagram illustrates the major functional relationships of the data for the system and user side of the model for this scenario. The elements of the system have been represented as logically related families, arrays, or groupings. The cardinality of the relationships was determined by the elements that were the most likely to be prominent given this scenario.

The fit criterion for the data and entity relationships follows the entity-relationship data model in Diagram 9b. The criterion were identified by using the Volere requirements process 9b. The data is summarized in Table 9b.

Table 9b - Fit Criterion for Data Requirements

ID # Name of object/entity Purpose of class/entity Description of relationship among classes and entities Attributes of class/entity

9a.1 Master data record (agent) To provide a master id (primary key), a data record, and for interoperability among data sets All system entities will be able to be linked when a master record and ID for each user is established. Unique ID and primary and secondary keys for the data sets, and knowledgebases

9a.2 Error/fault checking (system object) To enable tracking, management, and processes for fault checking and error reduction throughout all entities of the system All entities of the system will be connected by the agent objects for the execution of the error/fault checking processes. Shared object-oriented relationship attributes among entities, a unique ID for users, primary and secondary keys for the data sets, and knowledgebases

9a.3 Consent, security, and permissions - verify/create (system object) To establish consent, security and permission parameters, maintain a secure record for each user, and enforce consent, security, and permission protocols All system entities of the system will be connected by agent objects that will establish consent, security and permission parameters, maintain a secure record for each user, and enforce consent, security, and permission protocols. Shared object-oriented relationship attributes among entities, a unique ID for users, primary and secondary keys for the data sets, and knowledgebases

9a.4 Affiliated systems of the healthcare supply chain (system object) To create/update linkages among all affiliated systems of the healthcare supply chain so they can exchange data and information All affiliated systems of the healthcare supply chain will be linked by the system objects Shared object-oriented relationship attributes among entities, a unique ID for users, primary and secondary keys for the data sets, and knowledgebases

9a.5 Technology/intelligent agents (system object) To find the best-of-the-breed interfaces and tools that will allow the system to optimize and tailor experiences and sessions for users The agents and objects that relate to user interface and the entities that use intelligent systems processes will be linked by the technology agents Shared object-oriented relationship attributes among entities, a unique ID for users, and primary and secondary keys for the data sets

9a.6 Personal profile database - verify/create (agents) To verify/create a personal profile of key psychographic variables that will be used to tailor the interface, content, and services for each user All of the interface, communication, production, and delivery entities for the system users will be linked through agents to the personal profile and knowledgebases Relational database attributes among the named entities, a unique ID for users, primary and secondary keys for the data sets, and knowledgebases

9a.7 Consent, security, and permissions - update (system object) To update granted/defined the consent, security and permission parameters, maintain a secure record for each user, and enforce consent, security, and permission protocols Same as 9a.3 Same as 9a.3

9a.8 Personal profile database - update (agents) To update the personal profile of key psychographic variables that will be used to tailor the interface, content, and services for each user Same as 9a.6 Same as 9a.6

9a.9 Tracking/benchmarking database (agents) To update/create benchmarks/track lifestyle/behavior/stage for each targeted behavior that will allow tailoring of content and services for each user All of the production, delivery, motivation and incentives, support network, and communication entities for the system users will be linked through agents to the tracking/benchmark database and knowledgebases. Relational database attributes among the named entities, a unique ID for users, primary and secondary keys for the data sets, and knowledgebases

9a.10 Practitioner notes/indices of progress (agents) To enable linkages among practitioners that will enhance the services for the user and help the entities of the system operate more efficiently All of the production, delivery, motivation and incentives, support network, and communication entities for the system users will be linked through agents to the practitioner/indices agents. Shared object-oriented relationship attributes among the named entities, a unique ID for users, and primary and secondary keys for the data sets

9a.11 Domain data and knowledgebases query (agents) To maintain the best and evidence-based practices from the domain data and knowledgebases All domain data and knowledgebases will be connected by the query agents. Shared object-oriented relationship attributes among the named entities and primary and secondary keys for the data sets

9a.12 Domain data and knowledgebases update (agents) To enable the domain and knowledgebases to be updated, optimized, and operate most efficiently and the interface, content, and services for the users can be of the highest quality All domain data and knowledgebases and entities of the system will be connected by the update agents. Shared object-oriented relationship attributes among the named entities and primary and secondary keys for the data sets

9a.13 Alerts and cues to action database (agent) To provide alerts and cues to action for the system users according to system protocols All of the system entities will be linked through the agents to provide alerts and cues to action Shared object-oriented relationship attributes among the system entities and primary and secondary keys for the data sets

9a.14 Generate content and services - agent (data warehouse) To enable the content data warehouse to generate content and services that is tailored for the user All of the system entities will be linked through the agents to the content data warehouse. Shared object-oriented relationship attributes among the named entities, a unique ID for users, and primary and secondary keys for the data sets

9a.15 Deliver content and services - agent (data warehouse) To deliver content and services that is tailored for the user All of the system entities will be linked through the agents to the content data warehouse. Shared object-oriented relationship attributes among the named entities, a unique ID for users, and primary and secondary keys for the data sets

9a.16 System probe and user feedback - agents (objects) To probe the system entities and users for feedback All of the system entities will be linked through the agents to probe for feedback. Shared object-oriented relationship attributes among the system entities, a unique ID for users, and primary and secondary keys for the data sets

9a.17 Record system probe and user feedback - agents (object) To record the feedback from the system entities and users All of the system entities will be linked through the agents of the feedback process. Shared object-oriented relationship attributes among the system entities, a unique ID for users, and primary and secondary keys for the data sets

9a.18 Incentives/motivation loop database - agent To provide incentives and motivation to the users that will facilitate behavior change All of the system entities will be linked through the incentives and motivation loop. Shared object-oriented relationship attributes among the system entities, a unique ID for users, and primary and secondary keys for the data sets

9a.19 Support network database - agent To activate the support network among the appropriate system entities to provide support for behavior change All of the named system entities will be linked through the support network database. Shared object-oriented relationship attributes among the system entities, a unique ID for users, and primary and secondary keys for the data sets

9a.20 Follow-up content - agents To produce follow-up content for the users All of the named system entities will be linked through the content data warehouse Shared object-oriented relationship attributes among the system entities, a unique ID for users, and primary and secondary keys for the data sets

NON-FUNCTIONAL REQUIREMENTS

The non-functional requirements are the product qualities that have been identified as being important for inclusion in the system. The system requirements for steps 10-17 are described in the sections that follow.

10. Look and feel

10a. The interface

The external style and appearance of the system and the user interface have been consistently rated by users as extremely important features of technology-based products. Although there are general design guidelines and principles for developers to follow, there is a great deal of variability of tastes and preferences among different population segments. Moreover, the tastes and preferences of users can change dramatically over time, especially as users transition from novice to intermediate users. Therefore, system interfaces that are designed to be intelligent, flexible, changeable, and adaptable over time can be much more warmly received initially and highly valued by users in the long term.

The system and the technology windows through which users will access it will be used by all types of people. Therefore, the system and interfaces must reflect the tastes, preferences, and skill levels and to be able to accommodate the gender, age, ethnic, language, and other forms of diversity within the entire user population.

There are several techniques that should be used to identify and define the tastes and preferences of the user groups. Focus groups, extensive usability testing, and product comparisons can be helpful for defining the initial design parameters of the system. Prototyping and real-time use testing data, can help agents to learn, adapt, and adjust the system interfaces to the users preferences.

A description of the spirit of the interface. This can be in the form of text descriptions or preliminary sketches of a possible interface. The intention of this section is to state requirements relating to the interface.

10b. The style of the product

The product should be designed to meet or exceed the expectations of the user. The appearance of the user interface for the system should be highly attractive, entertaining, or even fun, functionally efficient, and able to accommodate a variety of personal tastes and skill levels. For certain types of functionality the system would work best with a more authoritative and assertive, while other interactions would be more effective with a "Rogerian" style or supportive approach. Some sessions should promote high a degree of interactivity, while others would be more appropriate with a structured sequential pattern. In short, the style and interface should be as user-centric and tailored to each individual and audience as possible.

11. Usability requirements

11a. Ease of use. (This section describes your client's aspirations for how easy it will be for the intended users of the product to operate it.)

The requirements for ease of use should be consistent with the theme as stated in the previous sections. The system and interfaces should be matched to the preferences, taste, and training of the user. Although there is a great deal of learning and understanding that comes with using any system, the system complexities should be hidden from the user. The intelligence of the system should strive to accommodate to the user so that they receive an optimal experience. However, it is important that the interfaces should not be so dynamic and changeable that they become a distraction or deterrent to the user. The user must be the one that maintains control of the system and they can determine how much or how fast the system changes over time.

11b. Ease of learning. (A statement of how easy it should be to learn to use the product (range from zero time for products intended for placement in the public domain (for example a parking meter)

It is envisioned that the system will offer multiple technology windows through which the users will interface and interact with the system. It is likely that many of the windows such as a telephone, fax, computer will already be familiar to most users. In fact, the array of options will allow the users to choose the type of technology that meets their requirements and preferences. Other "low barrier" technologies such as touch screens, PDA's, and internet appliances will be available for users who want to try to more up in levels of technology sophistication. Assistive applications and tools such as speech recognition, interface agents, wizards, and tutorials will also help users during the learning and mastery phases. Embedded help, intelligent interfaces, and other forms of support must be available to users as they learn the system as well as when they want to progress or explore new areas.

Low barrier systems, guided learning, and intelligent interfaces will mean that the technology will not be out of reach for any potential user. All users should be comfortable interacting with the system within 2 10-minute sessions. Analysis of use patterns, learning and usability labs, and computer-based learning agents will improve the ease and performance of the learning process over time.

12. Performance requirements

12a. Speed requirements (Specifies the amount of time available to complete specified tasks)

The system that is envisioned will encompass a vast spectrum of complexity and sophistication of functional requirements and tasks. Each of the task will have acceptable limits of performance in terms of speed, however listing them individually is beyond the scope of this investigation.

Many of the transactions will be carried out on-line. Acceptable performance times (e.g. 2-10 second range) for most transactions can be thought of in terms of tasks that we have become familiar with such as calls and transactions over the telephone, use of computers to access the internet, use of credit cards at stores, and use of ATM machines, Most of these tasks are accomplished in near real-time, although many other tasks that are part of a chain of reactions may continue on after the user is done. On the whole, the speed of delivery and response will greatly surpass that of manual or traditional approaches.

A major factor for high-bandwidth tasks in determining the speed of the transactions is the speed of the telecommunications network and infrastructure. The intelligence of the systems, techniques such as load balancing, and the alternative channels available will help to alleviate "congestion" and work to optimization of the system performance.

12b. Safety critical requirements

There are several considerations that relate to the safety of the users of the system. On the surface, there are few safety issues involved with the actual interaction with and use of the system. Most users who perceive an actual direct risk would avoid using the system or a particular component. However, some concerns about how the information or services that are gained from the system have been raised. For example, physicians are concerned about users doing harm to themselves by taking information they have gathered from the internet or other sources. Some of the information is false, misleading, misrepresented, or does not comply with standards. Pornography, isolation, and "Internet addictions" are other areas of concern that have been raised. Privacy, confidentiality, and security of information that is transmitted electronically is another major concern for many.

12c. Precision requirements (desired accuracy)

The requirements must take into account the accuracy concerns that users of the system might have. 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.

12d. Reliability and availability requirements (the necessary reliability of the product allowable time between failures, or the total allowable failure rate.)

Users of the system should expect nearly constant access to the system and it's resources. A robust architecture and infrastructure are cornerstones of a reliable technology systems. Today, many information systems have been designed to achieve nearly continuous access. Design considerations such as eliminating or minimizing the number of single-points-of-failure type of components, built in redundancy, and backup systems have been proven to be effective for systems that rely on 24/7 service. Having multiple access channels is another feature of stable systems.

12e. Capacity requirements (specifies the volumes that the product must be able to deal with and the numbers of data stored by the product.)

In the system that is envisioned, massive amounts of data will reside in the array of data and knowledgebases. A great deal of the data will be available through open and public sources such as the Internet, call-in centers, businesses, and organizations. Other forms of data will be private, restricted, or provided on a fee-for-service basis. However, in a modular design that uses distributed data storage architectures, it is possible to store or access any of the data stores if rights and permissions have been granted to the user. Therefore, although the data sources are limitless, design techniques are available that prevent the quantity of the data from becoming a system-defeating issue.

13. Operational requirements

13a. Expected physical environment

13b. Expected technological environment

13c. Partner applications

As the system is an open architecture, modular, multi-platform, and multi-language environment, the system must be open. All entities of the system must be able to interoperate and communicate with all other parts of the system. The technology windows must be able to interface with other parts of the system. Agents must be able to communicate and operate efficiently. Elements of the system must be able to operate in any environment.

14. Maintainability and portability requirements

14a. How easy must it be to maintain this product?

14b. Are there special conditions that apply to the maintenance of this product?

14c. Portability requirements

As was stated previously, 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. All parts of the system must be able to be portable.

15. Security requirements

15a. Is the system confidential?

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

15b. File integrity requirements

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.

15c. Audit requirements

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.

16. Cultural/political

Are there any special factors about the product that would make it unacceptable for some political reason?

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 must 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. Ideally, the system will build on the strengths of this diversity.

17. Legal

17a. Does the system fall under the jurisdiction of any law?

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

17b. Are there any standards with which we must comply ?

It is beyond the scope of this study to list all of the standards that the system must function under. However, compliance with standards is a feature of the system.

PROJECT ISSUES

18. Open Issues

Most of the issues that are related to the product have been defined in the previous sections. Other issues and requirements may be identified in the various critiquing and brainstorming processes during the downstream stages of the SDLC.

19. Off-the-shelf Solutions

19a. Is there a ready-made system that could be bought?

19b. Can ready-made components be used for this product?

19.3 Is there something that we could copy?

The system is actually an amalgamation of components and modules from many subsystems that are designed to function together. Various forms of software and middleware will be evoked to facilitate the interoperability of the elements of the system. Concepts, principles, designs, and elements from such entities and systems such as the CDC, commercial sector, hospital systems such as Mayo, and organizations such as the American Heart Association, and institutions such as the Koop Foundation and the Guardian Angel project can be copied and adapted to this study.

20. New Problems

20a. What problems could the new system cause in the current environment?

20b. Will the new development affect any of the installed system?

20c. Will any of our existing users be adversely affected by the new development?

20d. What limitations exist in the anticipated implementation environment that may inhibit the new system?

20e. Will the new system create other problems?

With the planning for or introductions of any system that is this comprehensive a variety of new problems will be created or discovered. The changes that will arise because this type of system will affect the thinking and culture of individual users as well as the institutions and entities that are part of the healthcare supply chain. Prototyping and staged implementation strategies have been used effectively to help the problem discovery process as well as minimize the negative impact on the early adopters. Often the practitioners and agents of care and their culture are impacted by the introduction of new system, particularly if they were not involved at some point in the development process.

As this is a design study, the definition of the requirements for steps 21-27 have been skipped because they are beyond the scope of this investigation.

21. Tasks

22. Cutover

23. Risks

24. Costs

25. User Documentation

26. Waiting Room

27. Ideas for Solutions

On to SDLC 3 - Analysis of the system needs

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

You can send e-mail to Me.

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

Last Updated: December 10, 2001