Through the application of technology, it is possible to simultaneously support CSAP’s mission and transform the science of substance abuse prevention. Applications of technology are already commonplace in prevention science and include knowledge development, synthesis, transfer, and dissemination. In each of these areas, however, the pace of computing, communications, and information technology increases at such a rapid rate that to provide the best practices to the field, CSAP needs to actively partner with technology to create a well-developed infrastructure that avoids fragmentation of software development and expensive design failures. In other words, prevention science must move outside more traditional boundaries to form alliances with computer science, library and information science, and communications technology (CSIT) disciplines. These disciplines have already shown progress in working with others to deal with challenges of the scope and complexity as prevention now faces. Opening prevention science to such advances in CSIT requires the development of an action plan that delineates first steps and makes clear recommendations for funding strategies that support and coordinate an ongoing collaboration. In this paper we review some of the components that will be necessary for an action plan. First, we briefly present the needs of prevention service delivery and a model for a decision support system that encompasses these needs. Secondly, we elaborate on this model by weaving technological parameters within a human centered decision support system.

An accessible human centered decision support system increases the capacity for state-of-the-science prevention. A human centered decision support system for prevention is a notion that combines a number of concepts. While decision support is a common and widely understood form of design, the human centered system is a relatively new construct. The human centered system is one that facilitates the increased usability and accessibility of computers and communication networks. Areas of research and development in human centered systems include such things as the development of software for collecting and analyzing data, finding and tracking information, knowledge repository access, interdisciplinary research in human and * machine environments, multi-cultural document translation and understanding, and visualization system tools and presentation. Local service providers can use Human Centered Decision Support Systems throughout every phase of service delivery, and the following scenario depicts one possible path of usage.

Scenario: Local Service Provider

Samantha reached out and turned on the computer. There was the symbol Georgina had told her about - a funny little stick figure. She moved the mouse over to it and clicked. The Prevention Service Practitioner’s Guide started. She was surprised when the first thing that happened was the stick figure appeared on the screen and told her she could choose to use different ways to interact with the software and asked if she wanted to see how they worked. She did want to know and eventually settled on using her mouse and keyboard – just for practice – though she vowed to herself that she would try voice commands the next time. She wanted to move quickly on to program design, but there were all of these other interesting choices in front of her. She looked closely at the different choices. As she moved her mouse across each choice, a small box appeared and told her what that choice would do…She chose to go directly to program design. She knew what kind of program she wanted to have. The first screen she saw asked her to pick a prevention approach. She chose school. A video started and someone she did not know began to talk to her about school based prevention services. As the woman talked about the design of those programs and what they did, She found herself relaxing and nodding her head in agreement. The steps she would take in designing the program were highlighted on a bar below the video and she could see the arrow showing that she was at the first step.

The first step was different than she thought. Instead of figuring out how many staff she would need and what hours they had to work, the first step here was to understand the situation in which the program was to take place. She looked at the set of risk and protective factors that were targeted for her region. This was interesting – she was curious and clicked on a few of the risk factors she did not understand. The videos were helpful – she saw the buttons underneath and found she could play over some the video she wanted to see again. She was surprised to find she could play with the graphs as well - dragging the lines up and down or moving the bars helped her understand the relationship of things - but she really liked seeing how her town compared with the rest of the county, and with some of the other towns in the state. She could see why some risk factors were targeted here. Looked like a school based adolescent alcohol prevention program was and had been a good idea – but those outcomes from last year did not impress her. No change just wasn’t good enough.

She did not know when in the program she hatched her plan, but it was sometime after she left the first step and decided to look at examples of "best practices." She was looking through program examples when it hit her – they were trying to do too much at Peer Power; their program did not focus as these programs did. Right then and there she decided to change things. She wanted to have the Peer Power program look just like the one she found under normative beliefs. She went back to that area and when the program she wanted came up, she picked it as her underlying design pack.

Her next steps were easy. She defined her target population, then went to pick distinguishing risk factors. The program told her that there was a good fit between her targeted risk factors and the type of program design she had undertaken. The programmatic strategy section was a little harder and She kept going back and forth between the presentations of different interventions. She finally settled on one and saw she was moving forward to a step she know nothing about – evaluation.

She went over everything with Georgina. Before Georgina would go to evaluation, she suggested that they look and see what other people have to say. She did not understand what Georgina meant until the school based program discussion group material appeared on the screen. You are on the Internet now, said Georgina, and all these people are talking about prevention programs, see – we are not alone in this. For the first time, she began to feel like she was a part of something larger than just her little program, like if their program could make even a tiny difference it could all add up to something important. The program helped her write process and outcome objectives – something she had never done before. Before she incorporated them into her program design, she decided to take advantage of the expert consultation feature and sent her design to one of the state advisors. She was surprised when a message came back immediately to hit her audio button. Together, she and her advisor viewed the material and talked through it and She felt a lot better.

She retrieved her work and saw the arrow on measurement. She clicked on it. As she worked and explored, she found that there were different measurement tactics for process and outcome. She reviewed each of her process objectives and now understood how they fit in the reporting format. On the outcome side, she was relieved to find that the measurement strategy was blinking with measurement instrument choices already suggested. She stuck with the suggestions given to her, and the program returned to the design screen.

Later, she looked through the materials she had printed out. She had seen program descriptions before, but this material was so thorough – some of it was designed so it could be duplicated and handed out to her program staff. In addition, right here was a copy of the measurement instrument they were going to use. The program had printed out a copy of the instrument for her to use in planning, and she understood she would go back and get as many copies as needed when she wanted to do the first part, a phase called the pre-test. Here it was, she thought, looking at her computer - right on her desk -–not a window, not a gate, but a useful guide.

 

The software development effort required to create a system that supports prevention service design is imbedded in a larger collection of diverse people, cultures and organizations that create, use, maintain, serve and advance the science of substance abuse prevention. It is very useful to consider the entire collection as an enterprise rather than a assembly of separate and weakly linked components. Within that enterprise, the Center for Substance Abuse Prevention has a central, national sphere of influence. Any CSAP software development effort needs to recognize the enterprise context within which it is situated.

From an enterprise perspective, the overall effort is layered; each layer impacts the development of specific software. Generally, the enterprise technical infrastructure is separated into six layers: business requirements, systems software, applications architecture, hardware and network, data architecture, and infrastructure. These are briefly described below.

Business requirements - This layer addresses the needs of the users for whom systems are being developed. Of all the layers, this is a layer that will require most effort by those active in the prevention information domain. Those who know prevention best must lead the specification of prevention domain "business requirements". Different users have different needs and a plan about how these needs should be met requires forethought and development.

Applications architecture - This layer defines the applications that must exist to support the business requirements. Definition of each of the following layers needs to be an activity enriched by strategic alliances with CSIT. In this layer, the Prevention Science Decision Support System is a key application. It will be a fundamental software application that incorporates access to other software, previously termed "modules." These modules must be designed to work well with the fundamental software application, what Jon Rolf has called the "mother ship." The "mother ship" is conceived of as a universal docking platform integrating a core set of modules that explain CSAP programs, and cover topics in the science of prevention, including planning, implementation and evaluation. The mother ship would be in the public domain with public published application programming interfaces. The mother ship would be the host for CSAP initiated and proprietary modules. Among others, the modules could include grant writing, logic systems, strategic planning, need assessment, community resource assessment, best and promising practices, minimum data set management information systems, curricula, boosters, protocols, informed consent, evaluation design agents, knowledge base access, core measures, data entry and data analysis.

Systems software - This layer defines acceptable operating systems, database management systems, and protocols. CSAP must meet Federal guidelines, such as those set by the Division of Information Resource Management though these may be modified or suspended for individual projects. CSAP will need to consider an effort - led by alliances with CSIT - that sets standards for CSAP and for the prevention information domain in this layer and in the following layers.

Hardware and Network - The layer defines the computer platform, communications, and knowledge base storage and management environment. To some extent, this layer is also defined for CSAP by Federal rules; still there is much that CSAP can define that will influence specifications that are appropriate for the prevention information domain.

Data architecture - This layer includes a high level design that describes the data needs of the users and the infrastructure of the data administration organization that will manage the data design. This is usually invisible to most people. However, it is an area of intense effort involving CSIT experts and CSAP staff and consultants. For example, one might have a national set of standards for application programming interface, data sharing, or even data dictionaries for knowledge development, synthesis, transfer and dissemination, knowledge base aggregation and distribution, scientific advancement, process and outcome reporting purposes.

Infrastructure – This layer focuses on those components of the data processing environment that can be used by multiple applications and are developed and maintained by diverse, distributed organizations. The national effort will be decentralized - a distributed architecture with a prevention information domain paradigm. Ideally, the architecture needs to be implemented in a manner that supports independence, connectivity and modularity at each layer; the architecture should be robust and scalable.

 

The enterprise level prevention service technical infrastructure must be an information utility. The users should not need to care or know anything about the various layers. Implicit in this view is a consistent user interface wherever and whoever the user might be. The user interface will expose information resources not network complexity.

Within this enterprise approach, a prevention science decision support system can provide a rule-based approach and, in the longer term, expert system support, such as case based reasoning, will support the service provider. The evolution of a useful system can be accelerated and more robust when accompanied by the development of portable, independent modules. This is only possible if a uniform prevention science classification and taxonomic scheme is applied across all modules and accompanies development. These emerging standards must apply across modules and support common data structures, field nomenclature and content. Imbedded in the use of such an approach is also the assumption that the functionality required by the modules is exceedingly diverse. For example, modules might provide:

procedural assistance for construction and conduct of outcome evaluation

access to information about theories that relate to services

examination of best practices for various strategies and service types

review of literature that relates to services

collaboration with others who are conducting similar services

interaction with others engaging in prevention science

discussion of issues with experts

stepwise development of a logic model

conformance to a risk and protective factor framework

construction of a measurement model

matching of instruments to the service

selection of instrument

reception of instrument

automated collection of data

remote analysis of data

reduced reporting requirements

visual views of results.

A vision of a prevention science decision support system is one that recognizes that software designed to aid a variety of prevention science decision makers is both central and essential to the direction and implementation of other CSAP technology efforts. This vision needs to be designed to accelerate knowledge dissemination and utilization; to provide a reliable, provable basis for service design; and to support knowledge development. This vision should link, in as accessible a fashion as possible, specific types of information to support the decision-maker. Examples of this information include prevention literature, best practice databases, outcome evaluation results from programs such as the Community Partnerships, or reports from National Clearinghouses. It might also include core archival indicators of risk and protective factors validated in the various state needs assessment studies and community resource assessments.

It seems clear that in the face of such complexity, effective modular development would best be served by different software development teams whose members were selected in consideration of the task to be done - from different disciplines, skill and knowledge areas. A singular effort by a single developer to develop all modules would not be optimal.

An initial step in this approach is agreement on a top-level view of major elements of the prevention information domain to be encompassed by the functionality of the proposed system. One depiction of a top-level view is shown in Figure 1. In Figure 1, the service design is influenced by knowledge of prevention and prevention science. In addition, the results of need assessments, community resource assessment, and assessments of program capability are input into the service design process through the mediation of the risk and protective factor framework.

The risk and protective factor framework noted here refers to a set of factors associated with greater potential for drug use ("risk") and a set of factors associated with reduced potential for drug use ("protective"). The results of specific need and community assessments and program capability judgements, when placed into the risk and protective factor framework, can be used to align service provision with the indication of heightened risk or reduced protection in the geographic area served by the service.

The prevention service design is the target of the prevention science decision support system. From the design activities come process and outcome objectives related to the overall strategy of evidence based construction of action to reduce substance abuse through the provision of prevention services. Service delivery is conducted accompanied by the consequent monitoring of performance and measurement of outcome. Process recording and outcome reporting are part of the overall evaluative process that contributes to knowledge and the knowledge base while influencing subsequent assessments of need and resource. The portrayal in Figure 1 leads to an idealized view of how prevention works, but does represent fairly the relationship of important event structures related to prevention service design.

of the decision support system by including an unspecified, external knowledge sources and components of the interface design. The knowledge sources could be drawn from a diverse range of resources, such as library based bibliographic full text retrieval, practice experiences of others communicated through media, or collaborative discussion.

Figure 2 also specifies a critical element of user focused interactive system design that must be addressed -the interface. The interface is the system for most users. Achieving good usability of the system will require that attention be paid to the design of the user interaction component; in other words the perspective of the user about user interaction: how interaction works, what is done using it; how is anything done using it - this is roughly the concern of people working in the area of human-computer interaction.

The user interaction software is the code for which the user interaction design serves as the requirement specification. Still imbedded in the Prevention Service Design box are the decision support aspects of the system. These aspects may go beyond rules or inferences. A more complete manner of thinking about them would include aspects that capture experiential learning, such as case-based reasoning. Case based reasoning as an expert system term could be explained simply as an effort to capture the nature of experiential learning in computerized knowledge bases that would give advice to the inexperienced. Another aspect may incorporate the notion of intelligent software agents. These are software programs that may act in response to queries by locating and accessing information from various sources, filter unwanted information, integrate information from different sources or present information in a consistent manner while adapting over time to the users information needs and the evolving construction of the information domain that is accessed.

Applying technical design over the prevention service design process is a dramatic, courageous act. Changes in prevention technology practice involve re-inventing traditional prevention information resources and work processes for the sake of developing contemporary, useful information resources.

In turn, information resource development can be understood as a form of participative design. This is a fairly amorphous term in American computing, though it has an evolving tradition in efforts to implement workplace democracy in Europe. In America the term is used to refer to an approach to computer application design, such as prototyping, that supports a deep sense of shared purpose with the users. From the perspective of technical professionals, the approach utilizes three related processes that are sometimes indistinct in practice:

(1) participatory analysis, that is, task analysis conducted as a collaborative activity with the end-user stakeholders,

(2) participatory design, that is, the collaborative creation of high level and low level ideas for system functionality, affordability, and pragmatics, and

(3) participatory assessment; that is, the involvement of the users as collaborators - not data sources - in the evaluation of a design.

 

It is claimed by technical writers in the field, with justification, that the work on participatory design has been marginalized, partly because it deals with the boundary of human factors, cognitive and visual design, anthropology, social science, linguistics, and other fields converging on the focal point of technical design work involving humans and computing machines. The marginalization may originate with boundary problems, but a design ethic is not a marginal issue. The need for a design ethic comes from the act of technology practice itself, not from the social sciences. If so, the choices about how to conceptualize an organization embedded in every computer system are ethical ones that are critical to the success of the system. The literature about the relationship between design ethics and use principles is not instructive, and there is widespread acceptance of the view that the model of how designers work with organizations and the people in them is implicit. The nature of the model’s assumptions seems to clarify when the designer runs into difficulties. If one accepts the literature, these difficulties are legion and provide a healthy press in the chronicles of failure. This is not the path for CSAP to take.

When the designer runs into difficulties is not necessarily the best time to step back and examine design assumptions. A general model of information resource design must be one in which user participation is fundamental. The primary reason for design failures is the inappropriate organizational arrangements to support user participation in information resource development. In fact, prototyping itself can be a source of resistance to design. User requirements in design are the negotiated product of argument and resistance. Improvements in the work of prevention - a work of human interaction not technological innovation - are the basis for contemporary CSAP information resource development.

It is in making these arguments, where designer, user, context and situation are intertwined in a mating dance around information technology practice, that the literature has come around to notice the general rule that humans and their culture operate in different speeds when they invent technology and when they apply technology. This is nowhere a more noticeable factor than when technologists and prevention scientists interact. Physical design has moved much faster than application in information technology, yet application is woven as the final piece of the design process. As a practical corollary to this observation, prevention science already knows from culturally sensitive practice principles that use is the goal of design and the user is the final designer. This is a lesson that cannot be forgotten as technology practice in prevention changes. Use and experience with the work that is to be improved is part of a continuing cycle of technical and work design and implementation. The software development view must be one that is based on people using technology, not on technology using people.

The bridge between research and practice is built with technology. Alliances with CSIT, collaboration with prevention scientists, and CSAP participation in decisions that embed prevention science within the national information technology infrastructure will advance prevention - as well as initiate the development and application of supportive technology. The involvement of CSAP in the design of technology systems, services, training and education will provide true access to prevention knowledge for the prevention practitioner. CSAP needs to carefully consider their role in information resource development. As proposed, standard setting, seed funding, and articulation of government, non-profit, and private information resource development at an enterprise level is sustainable and appropriate to the public purpose of prevention. Currently, however, the policies regarding CSAP’s information resource development need to define and elaborate the focus and direction necessary to achieve consistency. To introduce more complexity and consideration in this process- not as planning steps but as implementation – is one challenge CSAP must face with forethought and consideration. Existing implementation structures need to be examined and re-designed. The development of a human centered decision support system is a large scale, long-term, multidisciplinary collaboration that must concern itself with the human purposes and goals which are at its core: in this regard prevention practitioners can make useful contributions. In technical terms, human centering encourages broader use of advanced technologies, easier navigation and mining of information resources by users, and allows users to develop and tailor services and applications easily to meet their needs. In this manner, CSAP can use technology to link prevention practitioners with ideas and knowledge while advancing prevention science. This will be a major contribution of CSAP in the 21st century - both as a public institution and as the public steward of prevention.