US20160156509A1

US20160156509A1 - Method and Apparatus for Implementing an Active Information Model

Info

Publication number: US20160156509A1
Application number: US15/004,195
Authority: US
Inventors: Mohammad Salim; Barbara Rossner; Ronald Barber
Original assignee: Corybant Inc
Current assignee: Corybant Inc
Priority date: 2000-01-19
Filing date: 2016-01-22
Publication date: 2016-06-02
Also published as: US9253050B2; US20080177768A1; US7328233B2; US20150256418A1; US20020035593A1

Abstract

A service support system has one or more computerized servers each coupled to one or more digital memories and to a network, software executing on individual ones of the one or more computerized servers from a non-transitory medium, one or more rule sets stored in one or more of the one or more digital memories, a plurality of interaction ports enabling two-way communication between the one or more computerized servers and individual ones of a plurality of different sorts of computerized communication devices using one or more of voice, text, email, and interactive display interfaces provided by the one or more servers, and instantiation and configuration functions accessible by users of the computerized communication devices, the functions to instantiate and configure active agents.

Description

RELATED APPLICATION

This application is a Continuation of co-pending U.S. Ser. No. 14/692,132, filed Apr. 21, 2015, which is a continuation of U.S. Ser. No. 12/025,206, filed Feb. 4, 2008 and now abandoned, which is a continuation of U.S. Ser. No. 09/765,964, filed on Jul. 30, 2004 and issued as U.S. Pat. No. 7,328,233 on Feb. 5, 2008, which is a Non-Provisional filing based on the U.S. Provisional patent application Ser. No. 60/176,983, filed Jan. 19, 2000, and entitled “Data Harmonizer”. Priority is claimed for the disclosure of the prior applications, and the prior applications are incorporated herein in their entirety by reference.

FIELD OF THE INVENTION

This invention relates to computer systems, and more particularly to creation of information models for managing a distributed information system. The invention has particular utility for creation and maintenance of enterprise information systems.

INTRODUCTION, BACKGROUND, AND SUMMARY OF THE INVENTION

There are several problems associated with a conventional “technology-centric” approach to developing Enterprise applications. These problems include a certain lack of flexibility in the final system and real or perceived non-conformance to user and business needs. An example of previous work done in providing a system that is responsive to business processes is described in U.S. Pat. No. 6,073,109, issued Jun. 6, 2000 for a Computerized method and system for managing business processes using linked workflows.
Two of the principal advantages of current invention are that it is based on a “user-centric” approach to creating an information system, and that it can be implemented incrementally.
To be of value in the decision process, an information system must be easy to implement and adaptable to emerging technologies and changing business needs. Its successful implementation incorporates knowledge of the roles of the individuals and the workflow within the enterprise. Additionally, it is necessary to implement such an information system incrementally, allowing at all times for different parts of the enterprise to be at different levels of operational and technological maturity or obsolescence.
The basic theories of distributed systems incorporate four abstract operating perspectives. These are perspectives of Business Management, Application Developer, Service Provider and User. Although this model represents the users' perspective, it implicitly assumes that the information system belongs to the one enterprise and the users' perspective is in the context of their relation to that enterprise. We feel, however that user centric information systems must reflect the dimensionalities of the users' universe beyond those mandated by their employers. By using the example of professional practitioners in regulated industries, we were able to include a quantifiable attribute of a professional's universe that transcends the consideration of a single enterprise.
Need for a User Centric Information System
A fundamental premise of the invention is that “the user is the primary focus of the information system”. To understand why this approach may be unique now we can reflect on the evolution of information systems.
Focus on Building Better Computers
There is hardly anything that we do with computers that does not find its way back to A. M. Turing. It is possible that the reason for this strong affinity is Turing's unmistakable genius. It is also possible that we are trapped by the clarity of Turing's ideas. Turing's landmark paper [1] poses a simple question “Can machines think?” This seemingly innocent question locked the focus of information systems on technology for the last 50 years.
When we think of the people who have contributed to the development of information systems we think of physicists, mathematicians and engineers, not coincidentally, individuals with the same love for the abstract as Turing. It is interesting to think of what may have happened if Turing had stated a different question. Who would have been the designers of information systems today if Turing had asked, “Can people use these machines to an advantage?” Or simply “are computers really worth all the trouble?”
It was inevitable that once people outside of the closed circle of scientists and engineers started using the computers, people would find a way to make them more useful. The interesting question is what took so long? We can spend a few minutes and ponder how would we have thought about information systems if humanity had approached the information revolution with a bias toward “the domain of the problem” rather than “the domain of the solution”[2].
Information System is a Commitment not a Project
This is not idle curiosity. The fundamental technology of information systems, i.e. software, has consistently resisted economies of scale. One reason for this may be that up to now, in an information system the only acceptable specification can be presented in the language of implementation.
In other words we have a language for specifying other major undertakings such as highways or buildings, that allows us to think of them in terms of what is needed but in information system we only think in terms of what is possible or what is “cool”. That is, a “technology-centric” model for an information system.
As the information revolution progresses and non-programmers begin to rely on information systems, the information industry has no choice but to assume a broader perspective. Specifically, we are beginning to realize the extent to which an information system in each phase of its lifecycle, be it specification, development, or deployment, is an organizational commitment (a process), and not an individual or departmental task (not a project).
The Individual and the Collective
At the very core of the invention we start with the benefit of hindsight captured in one simple question that is to be answered independently for every single individual who is to be served by the information system: “what will the system do for me?” which is only the prelude to asking “how can I make it do what I want?”
The social implications of these questions are much more significant than may appear at first glance. There is a very good reason that software and system vendors and even many Internet businesses adopt a Business to Business (B-to-B) model and risk their business objectives to the long sales cycles and uncertain outcome of attempting to sell their products to the Fortune 1000 companies. Information systems are fundamentally focused on computers, which are only effective if they are handling abstractions (i.e. running programs).
From the point of view of a programmer, organizations, and in particular large organizations, are information abstractors. From the point of view of information management an organization is an abstraction of information needs for groups of individuals. If you start with the question “can we make a smarter computer?” the resulting product will make more sense to the larger enterprise every time.
On the other hand, the convergence industry, i.e. the industry that is concerned with information management and communication in a world of global commerce, wireless devices and Internet, is learning something about the value of being able to serve an individual, independent of their “current” employers. In this industry a company's net worth can be measured in terms of the number of subscribers that it serves. This value makes it worthwhile to answer a direct question “how can we serve this user?” But the traditional approach to design of information systems is preoccupied with building smarter computers and answers this question indirectly, if at all.
The convergence market requires a strong user centric element. A phenomenon similar to the evolution of long distance service providers and wholesale bandwidth merchants may make the delivery of information services a commodity in the future. If that happens, delivering information services to an individual in the context of both personal and professional requirements will pose an attractive business opportunity and may create a greater demand for true user centric implementations. Such a user centric information system must balance the traditional contention between “individualism” and “collectivism” [7] smoothly and consistently. We will refer to this need as “personalization”.
Retrofitting the Old Approach to the New Problem
A traditional engineering approach for personalization is to start with existing technology centric elements and develop a transformation that maps its attributes into the attributes of a user centric system. This approach is the common characteristic of architectural design methodologies including the recent object oriented approaches that are based on a formal definition of use cases [15].
A difficulty with this traditional approach is that these transformations tend to be non-linear i.e. they do not scale with the number of users or other changes in the scope of users' needs. However, when such changes occur, a non-linear transformation contributes its own artifacts into the solution, which are indistinguishable from the attributes of the problem space. For example it is difficult to ascertain if a certain behavior of the system is the result of implementation considerations or if it was a part of the original use case. Consequently traditional information systems tend to become an obstacle to the growth of the enterprise.
Another difficulty with this traditional approach is that these transformations are unidirectional because they are postulated, not calculated, as a result of a process of synthesis, which flows from requirement to implementation. Consequently a traditional architecture approach to information systems may identify deployment and maintenance as auxiliary processes that take place after the system has been designed, implemented, and validated. This approach is necessitated by the unidirectional nature of the transformation from the problem space (use cases) to the solution space (implementation).
In the end, users of information systems find that using an information service is effectively the same as joining an exclusive information club (a domain). Certain services are exclusively supported within the domain and the domain tends to have a life cycle, or a growth characteristic that is independent of the user.
Looking at the Information System as an Organizational Undertaking
The invention describes a method and an apparatus to serve the user. The method starts with the recognition that an individual user is a member of multiple enterprises. Within each enterprise, the invention attempts to capture a pragmatic specification of the user's information needs.
In a user centric system each enterprise is a forum for collaboration [4]. In other words, the invention assumes that the user's association with each enterprise codifies the user's information needs. This is an important concept that makes it possible to use a distributed computing environment to serve the information needs of the users.
The invention includes the concept that abstracting the users' roles within each enterprise creates an Information Model. The invention provides for continued evolution of this Information Model by making it possible for a user or a group of users to modify its or their behavior (we will refer to this as an “Active Information Model”).
An information system is an organizational commitment and as such the processes governing allocation of resources for its continued operation are a primary concern of the organization. Its specific attributes, such as the technologies that are included or the need for upgrading a certain service or a component become a concern only through such processes, for example if they are discovered to be in conflict with the organization's operational assumptions.
Multiple Perspectives
Furthermore, change is a reality of practice and it is a given that any information model (active or not) is always incomplete. The only reason that we consider any information model to be commercially useful is because it can be continually improved through formal processes [3][8]. If these processes are not supported, the implementation of the information model is faulty.
The apparatus that supports the invention serves two functions. As a component of a user centric system it must facilitate satisfaction of the information exchange agreements between the user and his/her collaborators. As a component of the enterprise's Active Information Model it must serve to contribute to the enterprise decision support processes for allocation of resources to the information system.
Extensive and excellent prior art exists in the area of characterizing an enterprise information system. Principally this work addresses the issues involved in implementing a service oriented distributed system [13], and the mechanisms for presenting system services as commodity items in a distributed environment [10], [12]. In general however, prior art is based on the assumption that the primary force governing an information system is the organization's mission or business objectives.
Early work in this area [6] describes four general perspectives that govern the evolution of an information system. These perspectives were identified as Management, Technology (Application Development [6]), Service, and User. In the development of the invention we found that a user centric system must accommodate additional perspectives that relate to the users' professional considerations, which in certain cases are independent of the business considerations of the enterprise. In an example of a specific embodiment of this invention (discussed in more detail in the “Detailed Discussion”), we choose to use a professional in a regulated industry as the prototypical user in order to extend the traditional model while at the same time maintaining a specific and recognizable relationship with a real world example.
Implementing the Engine
The operation of the Active Agent engine is described in detail in the Detailed Description of the Invention. Here, a few notes are appropriate.
The Active Information Model is a distributed system that:

- Describes the information management policies of the enterprise,
- Is never totally completed, although to the extent that it is described, it is accurate.
- Accurately reflects the organization because it is Active, i.e. it includes components that provide two essential services in the enterprise information system, namely information mapping and workflow.
- Is insensitive to the technologies that the organization uses to implement the underlying information system.

Interfaces
Certain unique attributes of the engine that support the active information model of this invention are based on its relationship to the users and the enterprise i.e. its interfaces, rather than its internal implementation. In essence these interfaces characterize the levels of integration, i.e. the way this engine relates to the computer based as well as human based segments of the enterprise information system. The engine is characterized by five interfaces. Four of these interfaces (Provider, Consumer, Configuration and Execute interfaces) are effectively exposed to the enterprise. The fifth interface deals with the way the engine retrieves its programming from the information model.
Workflow and Data Mapping
In this invention the combination of workflow and data mapping serve to make the active Information Model work.
The invention treats an action as an attribute of a role and not a service that is provided by the enterprise system. In a traditional enterprise application, an individual user can invoke an action. This causes the system to perform certain functions, which generally includes access to data sources. Changing system functions generally requires intervention by programmers. The concept of an Active Information Model in a user centric system directly supports situations where a user (or group of users) redefine a particular organizational function. For example, a supervisor may choose to change the way a service request is routed to a particular sub-group of his/her staff because they have had to move to a customer site for the day and are using PDAs instead of workstations for communication.
This local and transient nature of workflow is closely coupled with data mapping and the need for its redefinition to be configurable at the user level. To implement this, the inventors have defined a concept of a Command, for a lower level activity which is similar to system services in a traditional system, and have created a higher level abstraction of Actions as an externally visible attribute of a role that can be invoked by other roles.
It should be noted that Workflow is not defined by the aggregation of the actions but rather by the aggregation of the roles that include those actions. In other words Workflow is a statement of policy and the Active Information Model reflects this policy (moves information according to it) rather than implements it.
Information Mapping
The value of the engine of this invention to the information model of this invention is in the way it maps the information more than in its unique algorithms to move information at high speed. The engine is principally a mechanism for remembering the association of various elements of information in the context of a certain role within the enterprise. When an action is invoked the engine attempts to resolve all of the associations that are related to that action. In the process of resolving those associations various commands are executed and some data is moved.
There are two further concepts that are significant to discuss here, namely the use of reference categories and the use of facades. These concepts are discussed in some detail in the specification but it is worth noting here that they serve to contain the localized changes in the information model, making it possible to construct and maintain the information model incrementally.
Objectives
The methods, apparatus and systems of the invention are designed to meet the needs of professionals who collaborate with associates in multiple enterprises. To test fully the user centric aspects of the invention, it was determined that the above statement should be extended to meet the needs of certain business segments that have additional elements of cost or regulatory requirements. Therefore the design point for an embodiment of the invention was chosen to include additional constraints by using as the prototypical user professionals who work in small to medium size businesses and who are part of a regulated or structured industry such as healthcare, legal or maintenance and repair services. In this regard, the objectives of the method, apparatus and system of the invention include the following metrics:

- Information systems and applications must be easy to purchase and provide an immediate return on investment (ROI).
- They must integrate easily into the existing environment and be easy to use.
- They should be configurable:
  - to allow the users to define their own environment relative to multiple business and professional associations.
  - to allow the businesses to incorporate their own unique business processes. “I want it my way, not the way a programmer thinks I want it” is a phrase heard over and over during market research interviews.
  - to accommodate improvements in the individual and/or organizations' operational practices.
- They should be compliant with current and emerging communication and reporting standards.
- They should be flexible, enabling access to a wide variety of communication devices, databases and data sources and possess the ability to change as personal practice and business processes change.
- Information management solutions must be scalable to allow the business to start small, yet maintain the ability to grow as business needs dictate.
- Technology must be supported, if not embraced, by information services (IS) professionals (i.e. consultants and systems integrators) to allow professionals to enlist knowledgeable support as the need arises.
- Technology must support, not dictate, the business operations and users' needs.

With these objectives in mind, the result of deploying the Invention is a virtual, interactive, information management system that is not uniquely dependent on any server or any specific apparatus for its operation. The implementation of the system can use a variety of electronic data processing devices to assist the users' interaction with the system and data storage servers and communication links to provide for storage and transmission of persistent information. Examples of suitable electronic data processing devices may include workstations, laptop computers, and hand held data entry and communication devices, and others that may be developed in the future. The choice among these devices is based on the needs of the users of the system and the system itself is not dependent on any apparatus. The primary governing factors in the information system that deploys the Invention are the processes that the user community has adopted, in contrast to a traditional information system that imposes processes that facilitate use of its components.
The concept of “process” as used in the context of The Invention indicates a continuous focus by the participants on achieving a common objective. Specifically, and for the purposes of information management, a process is the formal element for managing the probability of success during the course of an activity.
The active elements of any process in an organization are the individuals who participate in the process. Within the framework of the governing process, these individuals evaluate progress, and redefine and execute the specific actions that result in improving the probability of success. An information system that serves such a process must facilitate this continuous redefinition and execution of these specific tasks. It follows that a critical attribute of the Invention is its ability to represent an existing process in a coherent, active information model whose behavior is continually updated and reconfigured by its users.
A significant function of the invention is the creation and continuous improvement of an information system by the individual or organization that deploys a computer system to serve an enterprise. The Information Model of this invention:

- Identifies the individual roles within the organization,
- Identifies location and characteristics of sources and destinations of the information elements that are used or created by each role (the relationship of each role to the data),
- Specifies the rules of translation between elements of data, from the perspective of each individual role,
- Specifies actions that are taken by each role relative to the information (the relationship of roles to one another).

Among the components of the invention that support these features are:

- A persistent record that describes the above information for each role: Configuration
- A software program that uses this information to perform the specified actions for each role: the Active Agent Engine
- A formalism that provides for translating the needs of the organization into configuration records for each instance of the Engine: Process.

The invention is a method and system embodied in the apparatus of an Active Agent that facilitates implementation and deployment of adaptable collaborative enterprise-wide information management systems.
It includes a software program that can operate in conjunction with, and independent of other programs within a computer system. This program operates as a system service which means that it may receive its instructions from the users of the information system or from other objects or application programs that are either running on the computer in question or have the ability to communicate with this computer. (software Engine).
This Engine is, and is implemented using, a group of independent, homomorphic components with specific structure and interfacing rules (industry term: Objects). A current embodiment of this invention is exemplified in its prototype implementation within the framework of an Object Model. As the Engine is itself an Object, multiple copies of it may be present within the system.
Using this Engine in a network of computers makes it possible for the organization to create a living definition of an organization's information use and management practices (an Active Information Model). “Active Information Model” implies that this model is defined and modified as needed, and in real time, in order to reflect the organization's structure. It further implies that it is an integral part of the organization's daily operation. “Real time” means that in order to redefine the responsibilities of one component, other components within the system do not have to stop functioning. The primary benefit to the organization is the ability to create an information management system, substantially independent of its specific hardware and software components. Specific advantages of this invention include the elements of the software system as well as the Active Information Model and elements of an information architecture that, once adopted by the organization, makes the overall information system a living and changing component of the enterprise.
Advantages of the Invention Over Prior Approaches
The Active Agent Engine is a tool for tailoring enterprise applications to satisfy the users' requirements. It:

- Serves as the agent of the user (not as the glue between applications),
- Satisfies the user's information needs within the enterprise rather than forcing the user to deal with the information that is created by generic applications,
- Defines the enterprise's Information Management practices as an aggregation of the user's information needs.

SUMMARY OF THE INVENTION

This invention includes an active information model constructed from an aggregation of personal information portals containing an active agent.
In a preferred embodiment, the system of this invention can be offered as a network service providing for information access and exchange according to the individual users' preferences. The advantages of the system include the ability of users and organizations to deploy best of breed information services in an integrated information system that is created and managed by the business management, based on the needs of the business and preferences of the individual users. This combination of features permits the organizations to provide information services to their employees through a variety of communication devices as well as personal workstations and terminals.
Active Information Models
The highest level of abstraction with regard to the invention is the concept of Active Information Models. Every idea within the invention eventually finds a way to support the following notion. An Active Information Model is a distributed information system that:

- Describes the information management policies of enterprises.
- Although accurate in describing these policies to the extent that it does, it is never totally complete.
- Includes components that provide two essential services in the enterprise information system namely information mapping and workflow.
- The language of its definition reflects the organization's behavior and is relatively insensitive to the technologies that each organization uses to implement the underlying information system.

The four basic elements of the invention reflect these concepts in such a way as to facilitate a formal process for creation and maintenance of an Active Information Model for an organization. These elements are Roles, Data Sources, Relations, and Workflow.
The invention provides for definition and utilization of these elements, to the extent that is necessary to create and maintain an Active Information Model in an enterprise. The focus of the invention is on accuracy of this model and two essential qualities of the resulting information system i.e. serviceability and potential for change. Other essential qualities of the information system (such as performance, security, and availability) reflect the behavior of the implementation platforms.
The invention includes an apparatus for implementation and a method for specification of an Active Information Model. Although the principles of the invention are generally applicable, we have chosen to describe it in the context of organizations that operate within regulated industries. In doing so we feel that we have demonstrated the general nature of the device and method beyond current practices in design of information systems.
The basic theories of distributed systems incorporate four abstract operating perspectives. These are perspectives of Business Management, Application Developer, Service Provider and User. Although this model represents the users' perspective, it implicitly assumes that the information system belongs to one enterprise and the users' perspective is in the context of their relation to that enterprise. We feel, however that user centric information systems must reflect the dimensionalities of the users' universe beyond those mandated by their employers. By using the example of professional practitioners in regulated industries, we were able to include a quantifiable attribute of a professional's universe that transcends the consideration of a single enterprise.
Roles
The invention provides a mechanism to define a Role by specifying the activities in which an individual participates and the services that an individual requires within the context of the information system, in the course of fulfilling an assignment.
Data Sources
Data source is an abstract concept that encapsulates the origin and destinations of the information. We have used the generic term “data source”, in recognition of Microsoft's ODBC and OLEDB initiatives, which are significant contributors to the computer industry's ability to share information between disparate systems. Our use of this term, however, is broader than Microsoft's. We look at data sources as elements of the entire enterprise rather than a component of the computing environment within the enterprise.
A data source, as a fundamental element of an Active Information Model refers to any component of the overall organization where information is stored and is made available according to a well-defined set of rules.
Practically, for the purposes of the invention, we define a data source as any data storage mechanism within the information system for which a formal interface definition is available. This includes databases and application specific file formats and other Engines.
Categories
A Category identifies reference to a data source within a Role. Categories describe data sources (logical reference), how to access them (access parameters), and the treatment of the information. For example, a Category may be a database located at a specific location on a network where the actual data resides. Another Category may be a reference schema that describes the way data is organized or a facade, which is a description of the presentation of data.
Relations
Relations are formal, abstract attributes of an Active Information Model that characterize the relationship between the elements of data sources. The prototype implementation of the Invention included two classes of Relations, namely Associations and Rules.
Associations
An Association is a declaration that a relationship exists between two or more elements of different data sources. Associations do not imply sequence or cardinality. From the point of view of information system design, an Association is an abstract condition that must be satisfied in order for the Active Information Model to achieve steady state. The sequence of operations that lead to steady state may be implicit or it may be described in terms of a Rule.
Rules
Rules are the mechanisms that embody an Association.
In general, Rules are attributes of Relations and independent of Associations. At the simplest level, this independence may be perceived as a means to re-use a definition of a Rule in the context of multiple Association. Although this is an appropriate example of the relationship between Rules and Associations it does not completely capture the scope of this concept. For example, the Invention allows for implementation of a time-variant, parametrically defined Rule that generates independent events based on changes in values of elements within multiple data sources.
Workflow
The Workflow Management Coalition (WFMC) defines Workflow as: “The computerized facilitation or automation of a business process, in whole or part”. In the context of the Invention, Workflow refers to attributes of an Active Information Model that are concerned with movement of information between different data sources. Largely, Workflow is the element of the Invention that creates a unique instance of the Active Agent Engine, specific to the activities of an individual User. The prototype implementation of the Invention included two classes of Workflow elements, namely Commands and Actions. As a general rule, Workflow elements tend to serve as a “verb” in a sentence where Categories serve as nouns.
Commands
Commands are the lowest level operators for moving data from one data source to another. The most common examples of Commands in an Information System are select and insert (similar to put and get as used in network protocols). As a rule, Commands require parameters that qualify their targets. Specifically, the definition of a Command is not instructions to the Information System for movement of data, rather the execution of a Command starts the chain of activities that ultimately resolve the conditions set forth in the related Associations.
Actions
Actions are aggregations of Commands that are visible to the run time interfaces of the Engine. In general, Actions activate the portions of the information system that are specific to an individual user. Actions are high level events and include global parameters that specify the criteria for access to the data sources and the context within which information is modified.
It is important to recognize that the attributes of the Role govern the details needed for executing the task.
The Active Information Model is Measured in Terms of its Elements
The Active Information Model is higher level abstraction than the Information System that implements it because it captures the aggregate description of the “purpose” of that Information System from the perspective of its users.
As such, the Active Information Model includes only one type of element, the Personal Information Portal. The relationships of the users within the Active Information Model are reflected in the relationships of these Portals. For example if two users share information, then there is a mechanism within the portals to accommodate this sharing.
The general notion of a Personal Information Portal is not unique to the invention. The concept of using such a construct to include an “active agent” and to represent a User's involvement in one or more enterprises is unique. The further refinement of this concept, namely the methodology of creating Active Information Models to formalize the process of defining and continuously enhancing the usefulness of the Personal Information Portal is also unique. A Personal Information Portal as defined by the invention must have the following characteristics:

- It must be a component of a distributed system architecture (it is an “object” within a distributed environment)
  - have a persistent storage
    - perform certain functions within the distributed system including
    - methods (programs) that it inherits from its class
    - methods that are unique to its specific instance
  - can be instantiated (a new copy if it generated for a new user)
  - can be remotely accessed (send and receive messages)
- Its behavior is subject to modification by the User
- Is aware of its relationship with other Personal Information Portals within one or more enterprises, reflective of the users' associations.
- It supports multiple interfaces
  - Interface to the user, for performing its functions within the information system
  - Interface to allow the user to modify its behavior
  - Interface to other portals, external information services, and data sources
  - Interface to the distributed system to allow maintenance, monitoring and upgrade functions

The concept of Personal Information Portal as the primary dispatch mechanism for information services offers a simple solution of the technical issues involved. A personal information agent can keep track of all of the transactions that an individual performs by simply logging these transactions. It can also invoke the appropriate context sensitive encryption levels making it possible to distribute the same service to a variety of users with subscription to different levels of services.
In this way, this feature is similar to the notion of kWh meter at each home. The method involving the Personal Information Portal makes it possible for users to have ubiquitous access to network services. In addition, having this capability makes it possible for any vendor of application services to use an Internet service provider as the distribution mechanism for their product and for the users to be charged according to a schedule appropriate for that service.
The General Idea of an Active Agent Engine
The concept of an Active Agent as a component of a Personal Information Portal is unique to the invention. The Active Agent is one example of a class of devices that effectively provides this function.
The general function of an Active Agent within a Personal Information Portal is to create a single mechanism (a unifying language; both in terms of syntax and semantics) that gives the user a pragmatic and therefore simple means of specifying their intention for using the various service elements. Service Elements may be Information Services (programs), communication devices, information sources, or other system resources. The Active Agent is viewed as an engine, an active component that performs sequences of specific programmed tasks. It accomplishes its objective by enabling the user to specify their view of each Service Element in terms of the way the functions of that Service Element relate to other Service Elements.
Attributes of the Active Agent Engine that are significant from the standpoint of implementing a Personal Information Portal are that the Active Agent Engine:

- Can gain access to Service Elements
- Offers a unified view of the Service Elements to the user.
- Recognizes other Active Agent Engines as Service Elements
- Has specific atomic functions
- Has the ability to perform its functions in sequence as directed by the user or as triggered by other Active Agent Engines or Service Elements (is programmable and can accept trigger events).

Implementation of the Active Agent Engine
The Active Agent engine is an Active component, a program, which moves information between various data sources within a network of digital computers. A “data source” can be any collection of data for which a provider can be created. Examples of data sources are tab separated text files, spreadsheets, named fields in a form, or a table in a relational database. Active Agent engines are capable of communicating information in form of data and events i.e. an Active Agent engine can see data sources through other Active Agent engines and can send and receive events.
Creating an Active Information Model
An Active Information Model is a process. During this process the organization creates and continues to improve a formal and accurate description of who creates and uses the information, how they create and use this information, and in what forms. Ultimately an Active Information Model is a tool that will help with the process of improving the management of information within an organization. As a tool of process improvement, the Invention offers three important concepts that are somewhat independent and at the same time collectively provide a complete definition. These concepts (roles, categories and actions) have already been introduced, and will be discussed in greater detail in the “Detailed Description of the Invention.”
An additional concept that is an important element of the invention is the concept of Messages, as used commonly in distributed systems to signify a formal mechanism for transporting information.
These concepts are “abstractions” in the sense that each of them is a convenient aggregation of ideas and practices that satisfy the needs of a particular view within the enterprise.
Embodiment of the Active Agent
The Active Agent is an element of distributed application architecture and includes modular components that support workflow management, data mapping, and application linking. These components implement an information management system that is effective in a single workstation or a network of computers in a client-server model such as World Wide Web or an enterprise Intranet system.
Framework of the Invention
The technical foundation of the invention is rooted in the concepts of distributed, and service oriented approaches to computer system architecture. The purpose of the invention is to provide a framework for an information system that can serve users who are members of one or more professional communities (as well as other users), by providing them with a tool for participating and improving the formal processes of information exchange and collaboration.
While this invention applies to other users and to non-professional communities, most professional communities (such as legal, accounting or healthcare practitioners) have developed processes specific to their unique needs and are using a formalism that reflects their specific discipline (e.g. medicine, law, or finance). Industries that are formed around these professional communities have adopted these processes in creating the operational framework of the businesses that support each professional practice (e.g. health clinics, law firms, or accounting firms). Regulatory bodies or significant stake holders in these industries (e.g. government agencies or insurance companies) have further identified certain additional considerations in order to facilitate their support or monitoring of these industries (e.g. insurance forms, tax laws, or FDA regulations).
Collectively, these definitions and agreements impose a general structure on each industry segment. Each business within each segment incorporates additional refinements to this basic framework to derive its own unique operational policies.
This entire chain of agreements, conventions and regulations is subject to change as a result of political, social, economic or business considerations. In order to be effective, an information system that serves a business in a regulated industry must respond to these changes.
The traditional method of implementing information systems is most responsive to technological considerations and least responsive to the needs of the individual end user. This method makes it possible to create effective information systems for large enterprises where the needs of the individual users are secondary to the policies of the enterprise and where there is sufficient operational mass to warrant engaging computer specialists who continue to improve the enterprise information system. In many cases the organization continues to fund this costly and non-responsive practice based on the promise that the next technological advance will provide a significant improvement.
Smaller businesses and independent professionals generally use generic business software such as spreadsheets, word processors and e-mail as the primary automation tool and, in effect, create an information system. This is an effective approach and highly flexible but it lacks a formal structure and tends to fall apart when these organizations grow even slightly.
The Invention specifically addresses this problem by adopting a service view of computing resources and functions. Furthermore it provides a mechanism to capture and enforce the framework of a regulated industry, and presents this environment to the end users in such a fashion as to allow them to personalize its behavior to fit their individual needs.
In effect, the invention transforms any single computer, or network of computers, into a scalable information management system. The users can connect word processors, desktop database managers and spreadsheet programs to internet based application services, enterprise databases, legacy applications or simply connect them together to create an enterprise solution. Using the Active Agent, business managers can customize the access to and use of information how, when and where they want it.
Agents
The way that people use computers today is by stepping the computers through what the computers have to go through to accept or provide information. This makes it so that only people who know how a computer works, (programmers) can effectively work with it. Others (users) have to accept the information when and how the programmers deliver it. We can make it so that most Internet users can tell the computers what information they need and how they want to receive that information.
The way we do this is by having an agent for each user in the Internet. This agent is a program that can store and distribute information the user has provided, and can gather information the user has asked for, in the form they wanted to receive it.
These agents can communicate with other agents and other programs that are available on the Internet as services. By telling these agents what and how they want to deal with information, people can create a personal work space that they can reach from any where, using any device that is capable of interacting with the Internet.

EXAMPLES

- A service that calls you on your cell phone when you receive an email from certain individuals, looks up their phone number from your address book and offers to call the email sender.
- A mechanism that keeps track of the time that an attorney spends with clients. This may be based on their calendar, the time they spend with clients on the phone, and the time that they spend working on documents that are in the client's files on line. This service can present the attorney with an invoice authorization report and upon approval can connect directly to a billing service that automatically invoices the client.
- Services to keep track of all of household expenses, which are paid by check, using cellular phone or credit cards. At the end of the month, the service creates a simple spreadsheet to authorize direct payment from your bank account. This service can also make recommendations about transferring credit card balances or statistics on delinquent accounts with each lending institution.
- A filing system that keeps track of your communications with your clients and keeps them organized and cross-referenced. Such a system can be used to conduct detailed dialogue on multiple topics with clients without the fear of loosing track of a topic or activity. In the end, each conversation can spawn into a new enterprise.

The Analogy with LEGO Blocks; Differences
An analogy with LEGO blocks works well as a means of making people understand that simple, re-useable parts make up the whole of the system. But after that, the analogy becomes misleading because it is communicating an image of the system as a physical or even structural entity.
The issue here is that the beneficiaries of the Active Agent are constructing a description of their personal processes not of what those processes accomplish. In other words, the Active Agent is not about helping you build a house, rather it is about helping you put together a construction company. If we were going to stay with the LEGO's analogy, we should talk about the re-usability of the idea that:
“I like to line up two blocks and push them together to get a single shape made up of the two.”
This is not a trivial distinction. The core issue is that processes are more long lasting than the objects and structures that deploying those processes creates. Even more to the point “personal considerations” are primary and enterprise considerations define the set of constraints to meet.
The point of the concept as well as its value proposition (the answer to the question: why is not everyone doing this already) is in this distinction. People try to use physical objects to depict systems. This misleads the conversation because it introduces language that is not congruent with the subject. For example if we were to try to talk about theology using the language of finance we are likely to come up with a slightly different religion than would otherwise be the case (using language more suitable to the subject).
The core issue is in fact the choice for the linguistic considerations that is provided to the users when they use this approach to defining their information needs.

DEFINITIONS

A User is any individual who uses our service. We think that a user is a member of one or more “enterprises” which justifies their desire to use networked devices with the Internet as opposed to take a walk in the park or go to a movie.
An Enterprise is any formal collection of people who have something to do together. In our definition of an Enterprise, these people tend to create and access “information” in a formal manner (i.e. predictable, repeatable, with some objective in mind that reflects the common goal)
Internet Service is a service that is offered and delivered via Internet (or other linked environment). It may be any one of (and not limited to) an information content service (Wall Street Journal), an e-commerce service (the cheapest rate for flights to a particular city), or a link to an enterprise application (time and attendance or billing).
A Message is a string of characters with the appropriate structure that enables it to find its destination over the Internet. A message implies the existence of a protocol, an agreement on the syntax and semantics of a message.
How does the Active Agent Work
The Active Agent incorporates an agent that understands a few very simple concepts. These are:

- The user's role in the enterprise,
- The categories of services that the enterprise in general and this user in particular needs to deal with,
- The specific information in these services that this role and then this user cares about,
- The kind of messages that this role and this user responds to (a Role within the enterprise is a service).

Given these concepts, the User creates a program for their Agent by telling it the specifics of these general topics.
The statements for this program are generally in the form:
When I receive an “accept new client” message, create an information container and call it the same as the “name” of the client, as specified in the “client name” field of the client database whose ID field matches the ID that comes with the message.
In reality, once the user joins the service, presumable because they are joining an enterprise on-line, a general program for their agent is activated which they modify to suit their specific need.
Over time, this agent is getting smarter and smarter about the user. The agent's view of the user is really about the mechanics of the information that the user handles. This is why we call the programs for the agent “the Information Model” for the user and the collection of these programs the Information Model for the enterprise.
What Happens when You have an Information Model
Consider a situation where we have formal, accurate, and up to the moment information about the services that an individual has declared to need as a part of their everyday life for each of the enterprises to which they belong. Furthermore, consider that we are collecting daily statistics about the extent to which each aspect of these declared needs are being deployed, the quantities of information that are being exchanged, and the detailed cost of providing this information. Having the implicit (or explicit, as may be required by any applicable laws or regulations) consent of these individuals to help them with a more effective use of the network services gives the enterprise that offers this tool a significant advantage for managing its information resources.
The Key to Creating an Information Model
A key to creating an Information Model is the ability of the system to start with a simple model and to improve continuously, thereby reflecting the more sophisticated needs of the individual. If we try to create this model for the individuals, it will be very difficult to do. However, if we were to give the individuals a reason to offer this information about themselves, the model will improve itself.
As people delegate the mundane aspects of their daily work to their personal, Active Information Agent, these agents can provide a knowledge base of the economics of information management for each segment of the market. This information gives power to the members of this community because although their use of the information is individualized, at the level of using the mechanics of the Internet they represent a collective.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of an active information model in accordance with this invention.

FIG. 2 is a schematic diagram showing a “defining a role” feature of this invention.

FIG. 3 is a schematic diagram showing a “perspectives and views of information” feature of this invention.

FIG. 4 is a schematic diagram showing the “data sources viewed through roles” feature of this invention.

FIG. 5 is a schematic diagram showing the “reference category” feature of this invention.

FIG. 6 is a schematic diagram showing the “facades” feature of this invention.

FIG. 7 is a schematic diagram showing the beginnings of an information model in accordance with this invention.

FIG. 8 is a schematic diagram illustrating how “access to information is an attribute of roles” in accordance with this invention.

FIG. 9 is a schematic illustrating how “users are autonomous members of the community” in accordance with this invention.

FIG. 10 is a schematic diagram illustrating how the Active Agent Engine functions in accordance with this invention.

FIG. 11 is a schematic diagram illustrating the Active Agent Engine Integration levels in accordance with this invention.

FIG. 12 is a schematic diagram showing the “implementing personal information portals” feature of this invention.

FIG. 13 is a schematic diagram showing the “using a personal information portal” feature of this invention.

FIG. 14 is a schematic diagram showing an example: personal information portal in home healthcare.

FIG. 15 is an illustration of an “about box for the Active Agent Admin utility” interface element in an embodiment of the invention.

FIG. 16 is an illustration of an “Event Logging option” interface element in an embodiment of the invention.

FIG. 17 is an illustration of a “navigation view” interface element for an embodiment of the invention.

FIG. 18 is an illustration of an “edit view of a role” interface element for an embodiment of the invention.

FIG. 19 is an illustration of an “edit view of a category within a role” interface element for an embodiment of the invention.

FIG. 20 is an illustration of an “edit view of associations within a role” interface element for an embodiment of the invention.

FIG. 21 is an illustration of an “edit view of rules within a role” interface element for an embodiment of the invention.

FIG. 22 is an illustration of an “edit view of commands within a role” interface element for an embodiment of the invention.

FIG. 23 is an illustration of an “edit view of actions within a role” interface element for an embodiment of the invention.

FIG. 24 is a schematic diagram showing an example: organizational view of an information system for a Home Care embodiment in accordance with this invention.

FIG. 25 illustrates a decision support model reflecting technology considerations.

FIG. 26 illustrates a decision support model reflecting business considerations.

FIG. 27 is a general information flow diagram describing the operation of an information system for a Home Care embodiment in accordance with this invention.

FIG. 28 is a schematic diagram showing an example: a measurable subset of the organization for a Home Care embodiment in accordance with this invention.

FIG. 29 is a schematic diagram showing an example: QA function explicitly defined for a Home Care embodiment in accordance with this invention.

FIG. 30 is a schematic diagram showing an example: using generic roles and proxy roles for a Home Care embodiment in accordance with this invention.

FIG. 31 is a schematic diagram showing an example: implementation of SN OPEN for a Home Care embodiment in accordance with this invention.

FIG. 32 is a schematic diagram showing an example: practical deployment for a Home Care embodiment in accordance with this invention.

FIG. 33 is a listing showing an example: directory structure for a Home Care embodiment in accordance with this invention.

FIG. 34 is an illustration showing an example: role configuration model for the local network for a Home Care embodiment in accordance with this invention.

FIG. 35 is an illustration showing an example: role configuration model for certified coordinator for a Home Care embodiment in accordance with this invention.

FIG. 36 is an illustration showing an example: role configuration model for mobile caregiver for a Home Care embodiment in accordance with this invention.

FIG. 37 is an illustration showing an example: role configuration model for skilled nurses (generic) for a Home Care embodiment in accordance with this invention.

FIG. 38 is an illustration showing an example: role configuration model for a mobile RN role for a Home Care embodiment in accordance with this invention.

DETAILED DESCRIPTION OF THE INVENTION

In the discussion which follows, we will assume familiarity with the concepts discussed in the “Summary” above. We will first discuss the invention in terms of its systems. Then, we will discuss the invention with reference to the attached figures. Those figures include an illustration of a particular embodiment of the invention in a regulated industry, but the invention is not so limited.
Active Information Model
To be a useful element of a company's management decision process, an information system must be easy to implement and adaptable to emerging technologies and changing business needs. Its successful implementation incorporates knowledge of the roles of the individuals and the workflow within the enterprise. Additionally, it is necessary to implement such an information system incrementally, allowing at all times for different parts of the enterprise to be at different levels of operational and technological maturity or obsolescence.
The four basic elements of the invention reflect these concepts in such a way as to facilitate a formal process for creation and maintenance of an Active Information Model. These elements are Roles, Data Sources, Relations, and Workflow.
The invention provides for definition and utilization of these elements, to the extent that is necessary to create and maintain an Active Information Model in an enterprise. The focus of the invention is on accuracy of this model and two essential qualities of the resulting information system i.e. serviceability and potential for change. Other essential qualities of the information system (such as performance, security, and availability) reflect the behavior of the implementation platforms.
The invention includes an apparatus for implementation and a method for specification of an Active Information Model. Although the principles of the invention are generally applicable, we have chosen to describe it in the context of organizations that operate within regulated industries. In doing so we feel that we have demonstrated the general nature of the device and method beyond current practices in design of information systems.
The basic theories of distributed systems incorporate four abstract operating perspectives. These are perspectives of Business Management, Application Developer, Service Provider and User. Although this model represents the users' perspective, it implicitly assumes that the information system belongs to one enterprise and the users' perspective is in the context of their relation to that enterprise. We feel, however that user centric information systems must reflect the dimensionalities of the users' universe beyond those mandated by their employers. By using the example of professional practitioners in regulated industries, we were able to include a quantifiable attribute of a professional's universe that transcends the consideration of a single enterprise.
Roles
The invention provides a mechanism to define a Role by specifying the activities in which an individual participates and the services that an individual requires within the context of the information system, in the course of fulfilling an assignment. For example, the following statement is a part of the definition of a the Role of an Intake Coordinator in a home care agency:
“To OPEN a Case, the Intake Coordinator copies the patient demographic information from patient database into the Intake Form and sends this form to the RN.”
This statement identifies the following elements of the Active Information Model:

TABLE

Elements of the Intake Coordinator Role in a home care agency.

	Data sources	Patient Database and Intake Form
	Reference model	The collection of the data fields that describe
		Patient Demographic information and their
		relationship to the fields in the intake form
	Commands	SELECT information defined by patient
		demographic and Insert this information into
		the appropriate fields in intake form
	Action	OPEN a Case

By defining a Role in this way, the external sources (to the Information system) where information is created or used are identified. In abstract, a Role may be described as “external interfaces of the information system”. FIG. 1 shows a practical view of a Role, as a particular aggregation of the internal elements of the information system.
Data Sources
Data source is an abstract concept that encapsulates the origin and destinations of the information. We have used the generic term “data source”, in recognition of Microsoft's ODBC and OLEDB initiatives, which are significant contributors to the computer industry's ability to share information between disparate systems. Our use of this term, however, is broader than Microsoft's. We look at data sources as elements of the entire enterprise rather than a component of the computing environment within the enterprise.
A data source, as a fundamental element of an Active Information Model refers to any component of the overall organization where information is stored and is made available according to a well-defined set of rules.
Practically, for the purposes of the invention, we define a data source as any data storage mechanism within the information system for which a formal interface definition is available. This includes databases and application specific file formats and other Engines.
Categories
A Category identifies reference to a data source within a Role. Categories describe data sources (logical reference), how to access them (access parameters), and the treatment of the information. For example, a Category may be a database located at a specific location on a network where the actual data resides. Another Category may be a reference schema that describes the way data is organized or a facade, which is a description of the presentation of data.
Relations
Relations are formal, abstract attributes of an Active Information Model that characterize the relationship between the elements of data sources. The prototype implementation of the Invention includes two classes of Relations, namely Associations and Rules.
Consider the statement:
Patient Name on HCFA 485 form includes Last name, First name and Middle initial from the patient record. HCFA requires that Patient Name be specified as Last name, First name middle initial
This statement describes the Relation between the element Patient Name in data source HCFA 485 form and the elements First name, Middle initial, and Last name in the data source patient record.
Associations
An Association is a declaration that a relationship exists between two or more elements of different data sources. In the above example the following Associations exist:

TABLE

Example of Associations

HCFA

485 form	Patient record

	Patient Name	First name
	Patient Name	Middle initial
	Patient Name	Last name

Associations do not imply sequence or cardinality. From the point of view of information system design, an Association is an abstract condition that must be satisfied in order for the Active Information Model to achieve steady state. The sequence of operations that lead to steady state may be implicit:
{Data source 1: element 1==Data source 2: element 5}
Or they may be described in terms of a Rule.
Rules
Rules are the mechanisms that embody an Association. In the above example the Rule relating to the Association is:
Name <=Last_name<,>First_name <sp>
Middle_initial).
In general, Rules are attributes of Relations and independent of Associations. At the simplest level, this independence may be perceived as a means to re-use a definition of a Rule in the context of multiple Association. Although this is an appropriate example of the relationship between Rules and Associations it does not completely capture the scope of this concept. For example, the Invention allows for implementation of a time-variant, parametrically defined Rule that generates independent events based on changes in values of elements within multiple data sources.
Workflow
The Workflow Management Coalition (WFMC) defines Workflow as: “The computerized facilitation or automation of a business process, in whole or part”. In the context of the Invention, Workflow refers to attributes of an Active Information Model that are concerned with movement of information between different data sources. Largely, Workflow is the element of the Invention that creates a unique instance of the Active Agent Engine, specific to the activities of an individual User. The prototype implementation of the Invention includes two classes of Workflow elements, namely Commands and Actions. As a general rule, Workflow elements tend to serve as a “verb” in a sentence where Categories serve as nouns.
Commands
Commands are the lowest level operators for moving data from one data source to another. The most common examples of Commands in an Information System are select and insert (similar to put and get as used in network protocols). As a rule, Commands require parameters that qualify their targets. In the above example a Command:

- select First_name, Middle_initial Last_name
  - from patient_record
  - where Patinet_ID=this_patinet

identifies a source of information and the criteria for retrieving this information, and the Command

- insert patinet_name into HCFA 485 form

identifies the logical destination of information in the context of the Role that is executing this Command. Notice that the identifiers for the elements in each case reflect the definitions within the target Category. Specifically, the definition of a Command is not instructions to the Information System for movement of data, rather the execution of a Command starts the chain of activities that ultimately resolve the conditions set forth in the related Associations.
Actions
Actions are aggregations of Commands that are visible to the run time interfaces of the Engine. In general, Actions activate the portions of the information system that are specific to an individual user. Actions are high level events and include global parameters that specify the criteria for access to the data sources and the context within which information is modified. For example, consider the Action Admit in the statement:

- Nurse_Pat Admit Sick_Jack

This statement signifies that the Role Nurse_Pat includes a declaration for the Action Admit. It further signifies that the associated Commands used by this Action will use Sick_Jack to access the relevant data sources (in this case, a patient database).
It is important to recognize that the attributes of the Role Nurse_Pat govern the details needed for executing the task. From this perspective, the Action Admit is one such attribute.
Implementation of the Active Agent Engine
The Active Agent engine is an Active component, a program, which moves information between various data sources within a network of digital computers. A “data source” can be any collection of data for which a provider can be created. Examples of data sources are tab separated text files, spreadsheets, named fields in a form, or a table in a relational database. Active Agent engines are capable of communicating information in form of data and events i.e. an Active Agent engine can see data sources through other Active Agent engines and can send and receive events.
The Active Agent engine may be used in conjunction with a single utility that simplifies access to various data sources for a single user or device. An example of this kind of utility is one that creates a data source from multiple sources such as various databases, and stored documents within an enterprise information system. Another example may be a protocol converter for a device within a Health Information Management System.
A logical network of Active Agent engines may be used in a network of computers for the purpose of facilitating workflow. Under this scenario, the Active Agent engines act as the users' agents to communicate events to other application programs and move documents or other information containers according to the workflow specifications. Examples of this application are a find-me service, a document review and audit process, or e-mail forwarding and filtering mechanism.
The Active Agent engine also has the capability of moving elements of data sources. This capability is useful in situations where groups of users need access to different elements of a single body of information. An example of such an application is a long-term Care environment where various healthcare professionals communicate with each other through sending and receiving information that is associated with standard forms. In many of these situations, the access protocol follows a predetermined workflow that is specified by the professional community or a regulatory agency.
Each instance of the Active Agent engine uses a configuration model (for example a role configuration file) that specifies its associated data sources, Actions, Associations and Rules.
Using the Active Agent engine a user with access to a network of computers through a workstation, an Internet Appliance, a hand held wireless device, or a telephone or any other suitable device can input, export and review information from different databases or documents. The user interface may be a browser, desktop applications, Word processor, spreadsheet program, personal information management application (such as e-mail or contact managers) as well as many commercially available special purpose device drivers such as text to voice converters.
Integration Levels
The Active Agent engine provides the ability to associate or map together various data sources, apply Rules to the Associations and move information between data sources programmatically. The engine exposes this functionality to end users and enterprise system builders through interfaces that allow run time and design time reconfiguration. The interfaces address the needs of several levels of integration:

TABLE

Integration Levels

			IT	Value	Active
	Accepts		Program-	added	Agent
Interface	changes	User	mer	reseller	developer

Execute Interface	Run time	X	X	X	X
Data source	Design time		X	X	X
Provider Interface
Configuration	Run time	X	X	X	X
Interface
Data source	Design time			X	X
Consumer
Interface
Persistent Layer	Built time				X
Interface

Active Agent Engine Interfaces
Provider Interface
The Provider Interface allows the user to connect to the Active Agent Engine as a data source. The schema exposed is determined by the configuration of the Active Information Model as specified by the configuration of the chain of Active Agent engines between the interface and the data source. This interface supports two features in the design of the Active Information Model. First, it allows the end user to access any Active Agent data source through standard database tools. In addition, an Active Agent engine can treat another Active Agent engine as a data source.
Consumer Interface
The Consumer Interface provides for the connectivity to all external data sources. The Active Agent supports a single connection method and relies on Provider utilities to convert data sources to this connection method. The use of Provider utilities minimizes the dependency of the Active Information Model on the specific characteristics of any data source. However, it is prudent to use a commonly used data source interface as the consumer interface for the Active Agent. For example, the Consumer Interface for the prototype implementation of the Active Agent engine used OLEDB® as specified by Microsoft Corporation.
Configuration Interface
The Configuration Interface exposes the programming model that allows the definition of a Role and its external behavior within the Active Information Model. In principle, this interface can be exposed for run-time modification. However, the Workflow Reference Model as specified by the Workflow Management Coalition (WFMC) specifies a distinction between run time and design time operation of a workflow engine. Different implementations of the Active Agent engine may choose to expose this interface through controlled utilities in order to adhere to the WFMC reference model.
Persistent Layer Interface
The Persistent Layer Interface supports different methods of storage of the Active Information Model. For example, the prototype implementation of the Active Agent engine used a binary file to store Role definition records within the Active Information Model.
Execute Interface
The purpose of the Execute Interface is to provide a simple interface from which to cause Actions to start within the Active Agent Engine. This interface has one method, which starts an Action, and one event, which notifies the consumer's code that the action has been executed.
Creating an Active Information Model
An Active Information model is a process. During this process the organization creates and continues to improve a formal and accurate description of who creates and uses the information, how they create and use this information, and in what forms. Ultimately an Active Information Model is a tool that will help with the process of improving the management of information within an organization. As a tool of process improvement, the Invention offers three essential concepts that are somewhat independent and at the same time collectively provide a complete definition. This section describes these concepts.
Roles: The complete definition of the creators and users of information
Categories: Data sources, schema presentation formats of data containers.
Actions: Events that govern transmission of Messages between Roles
An additional concept that is a part of the invention is the concept of Messages, as used commonly in distributed systems to signify a formal mechanism for transporting information.
These concepts are “abstractions” in the sense that each of them is a convenient aggregation of ideas and practices that satisfy the needs of a particular view within the enterprise.
Roles
One of the most basic concepts in the Invention is the concept of a Role. A Role is a description of a collection of assignments, usually associated with an individual or group with a specific set of credentials. The following Table is an overview of the relationship between a Role and the flow of information.


Abstraction	Described in terms of . . .

Role	Qualifications of the individuals e.g. Registered Nurse,
	Certified Records Administrator, Bookkeeper.
Assignments	Objectives described qualitatively e.g. Admit a patient,
	Maintain patient records, manage accounts payable.
Tasks	Measurable goals e.g. complete intake form, perform initial
	case assessment, issue an invoice.

To satisfy the needs of creating and maintaining an Active Information Model in an organization that is a part of a regulated industry, it is sufficient to describe clearly the Roles within the organization. In fact, deeper abstractions will create an obstacle to exploring alternative approaches within the overall objective of improving information management processes within the organization. This is in contrast, for example, to the process of developing an application for a functional element of an organization (such as an accounting application) where it is necessary to categorize the tools that are needed in performing each task.
Within an organization that is a part of a regulated industry, it is the qualification of an individual practitioner, not the business needs of an enterprise, that determines the assignments that they can accept and the information that they need or create in order to meet the objectives of those assignments.
Categories
Within the organization, however, different Roles can collaborate because they share perspectives on information. A perspective is an agreement on how to view information. A category is an abstraction that identifies a “view” of the information that may be useful to a group of perspectives.
Using this framework, the following concepts are of interest in defining Categories.

- Data repositories
- Data repositories as viewed through Roles
- Reference categories
- Facades

The first two concepts are concerned with the sources of information whereas the last two deal with creation and maintenance of the Active Information Model itself. A good general rule in design of an Active Information Model is that reference categories are inventions that facilitate dealing with data repositories and facades are inventions that facilitate dealing with Roles.
Data Repositories
For the purposes of Information Modeling any persistent medium that may contain information is a data repository. For practical purposes the information flow in and out of a given data repository is subject to its specific characteristic. For example in the context of an automated document management system, a hand written document that will be stored as a part of patient's medical record is a valid data repository with somewhat complex interface rules. For the purposes of Active Information Models related to the use of the Invention, machine accessible data repositories are the primary consideration.
Repositories Viewed Through Roles
For all purposes, Roles appear as sources of information to other Roles. In practice, however, it is the view of information from within a Role that is of interest to other Roles.
For example in FIG. 5 the Supervisor can see Report form through the Role Practitioner. Here, Practitioner is providing a data source to the Supervisor. In practice, this concept is best implemented through the use of Facades, which makes it possible to manage access to data sources.
Reference Categories
Two significant problems in Information Modeling are initial creation and maintenance of the model. The reference category is a useful invention to help with this problem. Typically, a group of Roles within an organization contributes to accomplishing a particular objective. For example in a home care agency the Intake Coordinator opens a case and assigns it to a registered nurse who will then make an assessment and create the care program. During the period that the case is open, various professionals will access and input information related to it.
The Active Information Model is based on information that is used or created by each Role within the organization. The Reference Category provides a mechanism to aggregate the information that is used by a group of professionals in the course of completing an assignment under a single category. This mechanism allows a particular data repository to be redefined without effecting the rest of the Active Information Model.
Facades
Facades support a localized view of information. They provide a mechanism whereby a Role can declare its own view of a data source as a Category. For example, the Customer Service Role uses “Repair History” as a Data Source to be populated when a service request is issued. “Repair man” and “Parts Clerk” are two Roles that use “Work Order” and “Parts List” forms, respectively. It is likely that these forms will be modified from time to time based on considerations specific to those Roles. Each forms is presented to the Customer Service Role as a facade, which in turn declares its interest in information that is contained in this form as another facade, “Warranty Service Request”, to the supervisor Role. A service request issued from the supervisor Role can populate appropriate fields in these forms automatically even though the actual structure of these forms is only determined locally
Actions
Actions are encapsulations of formal events that govern transmission of information between roles. In practice, Actions reflect organizational functions or individual assignments. The Active Agent exposes Actions as the external active interfaces to a Role. Within a Role, an Action defines a unique sequence of Commands, the atomic level operators that describe the movement of data between data sources.
Preferred Embodiment of the Active Agent
The Active Agent is an element of distributed application architecture and includes modular components that support workflow management, data mapping, and application linking. These components implement an information management system that is effective in a single workstation or a network of computers in a client-server model such as World Wide Web or an enterprise Intranet system.
An information system can use the Active Agent in a number of ways and embodiments in addition to those discussed above, including methods and systems that are integrated into a single device/method or in modules. The following is a brief description of the preferred embodiment of the invention.
Active Agent Servlet
The Active Agent servlet is a web server component that can turn a web site into an element of an enterprise information system. The servlet is responsive to commands that it receives form a web client or another site. It can connect to data sources on the World Wide Web on behalf of the user and it can prepare information according to a predefined format. The Active Agent servlet is a tool for personalizing information portals.
Active Agent Client
The Active Agent Client is an office automation tool that enables standard office utilities to be used in conjunction with a business's processes to transform any workstation or group of workstations into a scalable information management system.
Active Agent Administrator Utility
The Active Agent Administrator Utility is a program for the information manager installed in each system or database administrator's workstation or a web server. This utility provides the mechanism for the creation and modification of the harmonization Rules used by the Active Agent engine or servlet.
Connectivity Modules (Data Source Providers)
Connectivity modules perform the appropriate data translation and message transformations to and from each data source.
System Designer Workbench
System Designer Workbench is a simple tool that enables application developers to describe their requirements from a pre selected set of application services and the System Designer Workbench software will select the appropriate components. System Designer Workbench components will include a database that maintains the customer's configuration and a prototyping tool used to explore alternative configurations. This capability will support the following features:

- Component selection and purchasing
- Remote configuration management
- On-line IT management

Active Agent Build Environment
The inventors have successfully developed a prototype embodiment of the system of this invention, using the following build and test environment.

- WinNT 4.0 with SP 4
- Visual C++6.0 with SP3
- ATL 3.0
- MFC 4.2
- Visual Basic 6.0 SP3
- MDAC 2.1 SP1
- Installshield For Visual C++6.0

Test Environments

- Win98
- Install MDAC 2.1 SP1
- Win95
- Latest SP
- Install DCOM
- Install MDAC 2.1 SP1
- WinNT
- Install MDAC 2.1 SP1
- Install SP4

Now that the invention has been described, we will further explain the invention with reference to the attached figures. For ease of understanding, the figures may be grouped as follows (Groups A through G):
A. General Concepts

- FIG. 1 Active Information model
- FIG. 2. Defining a Role
- FIG. 3. Perspectives and Views of Information
- FIG. 4. Data Sources viewed through roles
- FIG. 5 Reference category
- FIG. 6. Facades

B. Creation of Active Information Model

- FIG. 7. Beginnings of an Information Model
- FIG. 8. Access to Information is an attribute of Roles
- FIG. 9 Users are autonomous members of the community

C. Active Agent Engine

- FIG. 10. Active Agent Engine functions
- FIG. 11. Active Agent Engine Integration levels

D. Personal Information Portal

- FIG. 12. Implementing Personal Information Portals
- FIG. 13. Using a Personal Information Portal
- FIG. 14. Example: Personal Information Portal in Home Healthcare

E. Initial Embodiment of the Active Agent Engine

- FIG. 15. About box for the Active Agent Admin utility
- FIG. 16. Event Logging option
- FIG. 17. Navigation view
- FIG. 18. Edit view of a Role
- FIG. 19. Edit view of a Category within a Role
- FIG. 20. Edit View of Associations within a Role
- FIG. 21. Edit View of Rules within a Role
- FIG. 22. Edit view of Commands within a Role
- FIG. 23. Edit view of Actions within a Role

F. Pilot Application

- FIG. 24 Example: Organizational view of an Information system for HomeCare
- FIG. 25. Example: Decision support model reflecting technology considerations
- FIG. 27 Example: General Information flow
- Table 27-1. Example: Summary of forms identified in FIG. 27
- FIG. 28. Example: A Measurable Subset of the Organization
- Table 28-1 Example: Attributes of the Measurable Subset
- FIG. 29. Example: QA function explicitly identified
- FIG. 30. Example: Using generic Roles and proxy Roles
- FIG. 31. Example: Implementation of SN OPEN

G. Pilot Implementation

- FIG. 32. Example: Practical deployment
- FIG. 33. Example: Directory Structure
- FIG. 34. Example: Role Configuration models for the local Network
- FIG. 35. Example: Role Configuration model for Certified Coordinator
- FIG. 36. Example: Role Configuration Model for mobile caregiver
- FIG. 37. Example: Role Configuration Model for Skilled Nurse (Generic)
- FIG. 38. Example: Proxy model for a mobile RN role

The figures will now be discussed, in turn.
FIG. 1 Active Information Model
An Active Information Model is an abstract view into an information system that reflects the operational practices of the individuals who participate in that Information System (users). An Active Information Model is characterized by a single abstract concept, a Role, which represents the interest of an individual user in the information system.
Role:
A Role corresponds to a position in the organization characterized by the qualification of the individual who represents a functional element of the organization e.g. Registered Nurse, Certified Records Administrator, Truck Driver, Test Technician. Functions that are performed by a Role are described as assignments and tasks. Assignments are qualitative statement of objectives e.g. Admit a patient, Maintain patient records. Tasks are measurable goals e.g. complete intake form, perform initial case assessment.
From the perspective of the Active Agent implementation a Role is a conduit for aspects of the user's responsibilities within the organization that influence the behavior of the Information System.
The scope of influence of a Role is characterized by three additional abstract components. These abstract components are Data Sources, Relations, and Workflow.
Data Sources represent the persistent component of information within an Information System. A Data Source within a Role is represented as a Category.
Category:
Contains the description of the data source schema (data model). In general a category represents an actual source of data i.e. a service that delivers specific information in a predetermined form. Additionally, there are two categories that serve to represent the appearance of a Role to other Roles:
Facade:
A category that does not have a data source. A Facade provides an abstract schema (view) of the Role.
Reference Model:
A category that does not have a data source. It represents the core information model for the Role. The core “Reference Model” would usually consist of rules, associations, messages and actions.
The atomic component of a Data Source is an Element
Elements:
Descriptions of the components within a category. For example a fields within a table in a database.
Relations represent a formal definition of the value that a Role may place on Elements or groups of Elements. This formal definition is reflected within a Role as Associations and Rules.
Association:
Associations define a relationship between two or more Elements. Associations are normally made between Elements that match in type and format. When Elements need to be associated that do not match then Rules are applied to the Association.
Rule:
Provide the ability to merge, convert or modify Elements in a predetermined fashion. In practice, Rules are scripts with a list of parameters that map to Associations. Rules govern Associations but are independent from Associations thus allowing one rule to be applied to many Associations
Workflow represents the operational protocol of behavior within the organization and the trigger events for movement of information within the Information System. Within a Role, Commands and Actions represent a Workflow.
Command: (e.g. Apply a Query to a Data Source).
The command object has two modes, Execute and Design. The Design mode provides the functionality to build a command against a category, for example to get data from or insert data into a database. The Execute mode is applicable only to an instance of a command within a Role.
Actions:
Are aggregations of Commands for a Role and are externally visible. An Action is the mechanism through which a Role can request a task to be performed by another Role.
FIG. 2. Defining a Role
A Role is characterized in terms of its relationship to certain other information elements of the Information Model specifically other Roles and Categories (data sources).
The relationship of a Role to data sources is essentially a declaration that the Role has an interest in certain specific elements of those data sources. This declaration may be shared with other Roles as a Facade or as a Reference model.
Actions are a declaration of the functions that a Role intends to perform within the Information System, reflecting the functions that the user performs within the enterprise.
The declarations regarding Actions, Facades and the Reference Model are the core support structure for the collaborative relationships between the Roles.
FIG. 3. Perspectives and Views of Information
By declaring the nature of its interest in the elements of the Information Model, a Role specifies its perspective on the enterprise information system. Taken together, the aggregation of all the relationship of all Roles in an organization constitutes a unified view of the organization's information. In a non-user centric system, this aggregation is essentially useless since it is virtually guaranteed to be redundant and quite possibly contains conflicting and incomplete logic.
In a user centric system, however, these declarations are localized in the sense that they are only evaluated in the context of specific Actions, which are the formal abstractions of the tasks that each Role performs within the enterprise.
FIG. 4. Data Sources Viewed Through Roles
A fundamental attribute of a user centric system is the ability of a user to select the view of information that is appropriate in the context of performing a task. It is appropriate to assume that these views will change as a result of a variety of parameters such as the communication devices that the user may employ.
At the same time, various views of information that are provided to other Roles represent departmental or organizational policies. The system must provide for a mechanism that enables changes in these policies to occur at a different rate than the changes in user's environment. This mechanism is supported through creation of Reference Categories and facades.
FIG. 5 Reference Category
A Reference Category reflects departmental agreements. For example within the context of certain specific tasks the supervisor, the practitioner and the billing clerk can adopt a single view of a customer service voucher. This agreement creates a unified view of the organization's information resources and each Role can use this unified view as the definition of the relevant information for that specific task (a Category).
FIG. 6. Facades
A more localized view of information is supported through the use of facades. Facades provide a mechanism whereby a Role can declare its own view of a data source as a Category. For example the Customer Service Role uses “Repair History” as a Data Source to be populated when a service request is issued. “Repair man” and “Parts Clerk” are two Roles that use “Work Order” and “Parts List” forms, respectively. It is likely that these forms will be modified from time to time based on considerations specific to those Roles. Each form is presented to the Customer Service Role as a facade, who in turn declares its interest in information that is contained in these form as another facade, “Warranty Service Request”, to the supervisor Role. A service request issued from the supervisor Role can populate appropriate fields in these forms automatically even though the actual structure of these forms is only determined locally.
FIG. 7. Beginnings of an Information Model
An Information Model is a simple network of Roles and data sources reflecting the corresponding organizational structure. The formal model is a declaration of these elements and their relations.
A relationship between two Roles is declared in terms of Actions. (Shown as one way arrows in FIG. 7). The model assumes access to data sources (two way arrows in FIG. 7) as a consequence of the declarations within a Role, consequently Actions are the only substantive content of the communication between Roles.
From the perspective of a given Role, certain other Roles may be grouped together representing the organization's view of a department. Using the concepts of Reference Categories, Actions, and Facades, this aggregation can be treated as a Role, performing a service (Records, Administrative Services and Inbox in FIG. 7).
The aggregation of Roles may only be appropriate in a limited context. For example Roles 2 and 3 can appear as a single department to Role 1, but Role 4 can have an exclusive relationship with Role 3.
FIG. 8. Access to Information is an Attribute of Roles
The relevance of the Information Model to the practical operation of the enterprise is maintained by protecting the autonomy of the individual users in a distributed information system architecture. Within this architecture a message is a request for a service to be performed by a Role including the “context” of the service, (the data) rather than the presentation of that data.
In the example of FIG. 8 the Role “Supervisor” issues a (Service Request) to be performed by the Role “Service Technician”. The Service Technician performs this task and issues a (Service Performed) to the Role “QA Inbox” (represented here as an aggregation or a department) presumably to close the service request. QA Inbox verifies the completion of the task and issues (Invoice Request) to “Billing” and a (Close Service Ticket) request to Supervisor.
In practice, when the individual human being who is represented in the Information Model by the Role “Supervisor”, issues a (Service Request), he or she is filling out a form using the information that is relevant to authorizing the service and assigning the appropriate individual to perform it. This information may include product warranty records and information about a service individual who is available and qualified to perform the required task. The “Service Technician” will receive a message that includes substantively the need for this service to be performed and the relevant information which may include product history and customer's home address where the service is to be performed.
FIG. 9 Users are Autonomous Members of the Community
Furthermore, the presentation of this information to the individual Service Technician depends on the communication device that is available to that technician. FIG. 9 demonstrates an information model that supports three different modes of communications for a single generic Role of Service Tech. Notice that the Supervisor does not have to be concerned with the difference in the communication media because the generic Role Service Tech provides a uniform view of these resources.
In certain cases the user's connection to the information system requires inclusion of a Proxy Role. For example ST1 mobile device is not directly connected to the information system and ST1 Proxy Role serves as an agent for ST1 in the Information Model.
FIG. 10 Active Agent Engine Functions
The Active Agent is implemented as a software engine, a stand-alone executable element, within a distributed, networked computing environment. Each instance of the Active Agent engine represents a single Role within the information system. The definition of a Role, the Role Configuration, that is the program that controls the behavior of the Active Agent instance that represents that Role is stored in a database as a record or in a file system as a binary file.
The Role Configuration identifies Actions and the Commands that make up those actions, Categories, the relevant elements of each category, the associations between those elements, and rules that govern those associations.
Categories that are visible to a Role may be a data source, an external service or another instance of an Active Agent engine (another Role). Each Category is made available to an Active Agent instance through a Provider mechanism, which normalizes its unique information access protocol for the Active Agent engine.
FIG. 11. Active Agent Engine Integration Levels
In practice the Active Agent engine presents four external interfaces. The Command Interface exposes Actions and is seen by other Active Agent instances. The Consumer Interface exposes the data source Categories, the Provider interface presents a view through other Active Agent engines. The Configuration Interface provides access to the Role Configuration for each instance of an Active Agent (each Role) and can be used to reconfigure each Active Agent instance i.e. to redefine a Role. A fifth interface (not shown) is for access to the persistent information i.e. role definition records.
FIG. 12. Implementing Personal Information Portals
Personal Information Portals are mechanisms that enable an individual user to establish a personal view into one or more information systems in a distributed environment such as the World Wide Web or an enterprise Intranet system. A Personal Information Portal that implements an active Information Model will include the following components:
The Portal:
A view of the Information System that is presented to the user
Portal Agents:
Active Agent instances serve as Proxy Roles to serve user's preferred device configuration.
Enterprise Agents:
Active Agent instances that represent the structure of the enterprise Active Information Model (Roles).
Distributed Sharable Storage:
An information service that provides mechanisms for data sources that may be shared between users. This mechanism includes a Mass Storage Service which provides for Secure Storage and Archival Storage, as integral elements of the distributed environment.
Information Services:
Other services that are available to the distributed system such as news services or stock quotes.
Application Services:
These are specific functions that are external to the enterprise but necessary for the functions of the enterprise. Examples of these services are Credit card verification, or Time and Attendance applications.
FIG. 13. Using a Personal Information Portal
Using this model, the Personal Information Portal provides a mechanism where a group of users can create a distributed enterprise information that incorporates publicly available services. From the point of view of a single user, the portal incorporates an Information Agent who represents the user in each enterprise. Services that are available to the enterprise are offered to each user within the context of their specific Roles within the Information Model.
FIG. 14. Example: Personal Information Portal in Home Healthcare
Home Healthcare is an interesting example of a distributed enterprise that includes mobile professionals, diverse and regulated practices and a strong need for formal organizational structure that is imposed by government agencies and private insurance companies. Using the Active Agent to implement an Active Information Model a Home Care system can use the World Wide Web as the foundation of its information system.
FIGS. 15 through 23 demonstrate the user interface that was designed for the pilot implementation of the administrator utility for the Active Agent engine. This interface was designed to provide direct control over the operation of each instance of the Active Agent engine by creating the appropriate Role Configuration files.
FIG. 15. About Box for the Active Agent Admin Utility
This figure demonstrates the basic opening screen of the utility and the standard about box identifying the build version and copyright notice.
FIG. 16. Event Logging Option
Event logging capability is a key element of the Active Information Model. Using this capability, each instance of the Active Agent engine can maintain a record of the activities that it has performed. This information can be used for audit, billing, security and predictive allocation of computing and storage resources. The direct contribution of event logging to the process of information modeling is that it provides a mechanism whereby the organization can ascertain the specific cost of the information system to the resolution of a single role. This capability provides the measurable component of the “Practical Considerations” in the decision support model.
FIG. 17. Navigation View
FIG. 17 displays the navigation view of a Role Configuration file defining the function of Intake in the pilot implementation example for a home care agency. The role Certified Coordinator contains three categories of data sources (Table 1; a database table, Patient Reference; a reference model pertaining to a physical, regulated form, and SNOpen; a view of a facade that is looked through another role). A deeper view of the elements within Table 1 is also demonstrated. It is significant to note that these categories maintain a unified appearance even though the nature of the data sources that they represent can vary.
FIG. 18. Edit View of a Role
From the perspective of the function of responsibilities within an organization a Role is a container for the mechanics of definitions and an identifier of a resource. FIG. 18 displays a “Role Manager” screen that provides edit access to the internal definition of a Role, namely the Role Identifier as well as the categories, Associates, Rules, Commands, and Actions associated with that Role.
A fundamental attribute of a Role is its relationship to the Information Model and the associated Information System. To “Register” or “Unregister” a Role, the Active Agent engine adds or removes its corresponding organizational function from the pool of resources within the Information System.
FIG. 19. Edit View of a Category within a Role
The definition of a category within a Role includes three distinct considerations:
Identification of the Category:
This group includes the information that is needed to access and refer to a category. These include a name, the data source and component within that data source (such as tables or queries in a database).
Disposition:
These are attributes that identify the services that are available for the disposition of a category. Examples that are presented in this implementation were email or print insert. Other implementation may include a variety of services that are available to the system such as voice to text or text to voice services.
Perspectives:
These characterize the relationship of the data source to the Role. In this example they include Facades, Visible, Reference and disabled.
FIG. 20. Edit View of Associations within a Role
An association is a relationship between the elements of different categories. In the example above association is identified between “Secondary's Date on onset” in “PatientInfoReference” Category with “SecondDiagDate” element of “SNOpen” category.
An Association is an instance of an object within the scope of a Role. As such, a single association may connect multiple elements of multiple categories or it may connect these elements to Rules. The specific mapping of the values of these elements are not specified within the definition of an Association, only the fact that these elements are related through this association.
FIG. 21. Edit View of Rules within a Role
Rules define the actual mapping of the values of elements between categories. A Rule may be an interpreted script such as a Java or Perl script whose invocation arguments are the elements that are Associated with those rules. A Rule may also be an instance of an Active Agent primitive string or arithmetic operation as shown in FIG. 21.
FIG. 22. Edit View of Commands within a Role
A Command is an object within the scope of a Role that serves as an atomic level operation through which a Role attempts an access to one or more elements of a data source.
A Command can accept qualifiers to communicate to a data source such as a search parameter for a data base query.
FIG. 23. Edit View of Actions within a Role
Actions are a sequence of commands that are executed in order. Actions are visible external a Role and can accept parameters as Context (arguments to be supplied to Commands). In the test implementation the Active Agent engine accepted an additional, optional, qualifier (Role) to simplify the programming of the user interface.
The Application of the Active Agent: An Example
We will use the process of building an information system for HomeCare, a prototypical home healthcare agency, as an example in describing one type of problem that is addressed by the Active Agent. Home healthcare is a regulated industry and it includes:

- Patients who need a moderate amount of professional care on regular basis.
- Professional caregivers in a multiplicity of specialized disciplines. In most cases caregivers share caseload as a patient may need care in multiple areas or as the type and degree of care that is provided is responsive to the stage of convalescence.
- Healthcare administrators who oversee the operation of agencies. A home care agency is traditionally a small organization although recently the industry is demonstrating a trend toward consolidation.
- Payers. These include health insurance agencies that may be privately held as well as government institutions such as Health Care Financing Administration (HCFA).

We have chosen this industry to demonstrate an application of the Active Agent because it characterizes the behavior of an information system that needs to be User Centric in order to be effective. Specifically we are going to describe the relationship of the information system to the caregivers and healthcare administrators.
The Problem
To Harmonize: To adjust in fit proportions; to cause to agree; to show the agreement of; to reconcile the apparent contradiction of. (From Webster's Revised Unabridged Dictionary 1913)
Let us assume that HomeCare is a relatively small organization that works as an extension of a local hospital. Let us assume the administrators as well as professional caregivers associated with HomeCare have articulated its mission: “to provide a comprehensive range of home healthcare services to the community and strive for the highest level of professional and technical competence in those services”.
To meet the challenges of its mission statement, HomeCare must be organized to satisfy the professional needs of its employees, its own business needs, and the regulatory requirements as well as the medical needs of its clients, FIG. 24 provides an organizational view of an information system for HomeCare. Activities in this organization are substantially influenced by two external sources: the doctors and the payers. Additionally, regulatory considerations impose requirements from the perspective of quality and longevity of the patient records. Furthermore, professional and business considerations impose requirements with regard to timeliness of services and preparation of information relative to the services. Caregivers deliver the actual services that HomeCare offers according to methods and policies that are accepted by the Caregiver community in general and that are modified to fit the specific needs of the professionals who are employed by HomeCare.
FIG. 24. Organizational View of an Information System for HomeCare
Within this organization, policies regarding formal flow of information are based on:

- Agreements among individuals and groups,
- Job assignments,
- Government regulations,
- Policies of payers and doctors or client hospitals.

It is important to recognize that these elements are subject to change at various levels of the organization. For example caregivers need the flexibility to reassign caseloads in emergency situations, the administration may need to change operational policies, and payer plans and government regulation are constantly changing.
It is also important to recognize that these elements are primarily concerned with the practice of healthcare and not with technologies that may be deployed to perform the functions within this practice.
Moving Toward Automation
Let us assume that the management of HomeCare understands that the practice of information management represents a significant portion of the organization's responsibilities. Common wisdom, substantiated by practice in other industries, indicates that the proper use of “state of the art technology” in information management can improve quality and reduce operating costs. Let us assume HomeCare management identified automation as the key element for process improvement and undertakes a management initiative aimed at automating HomeCare's information management activities. Let us assume the objective of this initiative is:
“to develop a strategic plan and budget to support the automation of core business processes including tactical planning for interim computer operations, and the evaluation of appropriate available computer technology in moving toward an electronic patient record and total electronic bill generation”.
However, the definition of “appropriate available computer technology” is not a constant. On the average, using the technology life cycles of 1995-1999 as a basis of calculation, the life span of an automation tool is about ½ to ⅓ the time that it takes an organization in a regulated industry to make a measurable change in its operating processes.
Traditional Decision Process
Given the above statement of objectives and operational realties, it seems inevitable that the organization will move toward higher degrees of automation in phases. Each phase will involve allocation of funds and therefore a management decision process. A traditional decision process to prioritize the goals of each phase of automation follows the decision support model that is summarized in FIG. 25.
FIG. 25. Decision Support Model Reflecting Technology Considerations
This model identifies the elements of the decision process and highlights the relationships between these elements. It demonstrates the following principals:

- The overall objective is to improve the effectiveness of the organization toward performance of its mission (home care).
- Requirements for each phase of automation are driven by the need to automate some portion of the business.
- The specific goals of each phase of automation will be determined by the individuals or groups who are impacted and the state of tools and services that are affordable to the organization.
- The allocation of resources to each phase of automation will be driven by the realities of the business and the available technologies.

This decision process is somewhat intuitive from the perspective of supplying services and technology to this organization. It will serve to identify the resources that should be applied to acquisition and deployment of computing equipment and software. However this model is biased toward technological considerations. Since the mission of HomeCare does not involve mastery of information technologies it is not likely that HomeCare will have the staff and infrastructure to have up-to-date and accurate knowledge of available resources in this area. Consequently, there is a strong possibility that this decision will be made at the expense of the organization's ability to meet the objectives of its automation initiative.
It is a common experience that decisions based on this process tend to create conflict between the users and service providers. Practically, this process limits the practices of various departments to the capabilities offered by the primary vendor who supplied the last component of automation. Given the rate of change of technology, the fact that it may take the organization 6-12 months to adopt an automation component, and the nature of HomeCare's business that forces it to use products after they have been proven, the organization is essentially guaranteed to be using obsolete products. Phased implementation further exasperates the situation, making it practically impossible for HomeCare to effectively deploy technology.
An Alternative Decision Process
The decision support model of FIG. 26 demonstrates an alternate process that is to a great degree impervious to technology changes. Given such a model, the decision process for each phase of automation can be a continuation of the overall process of business automation and can benefit from the lessons learned form previous phases. Technology considerations, which are by nature variable, are still included in the process of implementing the infrastructure but they do not govern the process of automation.
This decision process is focused exclusively on the mission of HomeCare. From that perspective the primary goal of this process is to determine the resources required in order to meet the users' needs. The analytical considerations, which provide the guidelines for measuring success in each phase, are based on the strategic objective of improving the organization's ability to improve its Information Management Capabilities rather than a specific tactical need at a point in time. This approach offers a consistent means of defining the tactical goals of each phase.
In addition, the practical considerations are based on the organization's Active Information Model and not a sample of the state of implementation technology. In summary within this process:

- The overall objective is to improve the effectiveness of the organization toward performance of its mission (home care).
- Requirements for each phase of automation are driven by overall need of the organization to improve its ability to manage its information base.
- The specific goals of each phase of automation will be determined by balancing the need to improve information management practices and affordability of the underlying technology.
- The allocation of resources to each phase of automation will be driven by the realities of the business and the long-term strategy to move toward automation.

Although this approach seems reasonable and even attractive, it has not been practical because it assumes that the organization has a consistent Active Information Model that (1) is described using the terminology of the organization's primary mission and (2) can be used to control the behavior of the information system.
The inventors' Active Agent provides the mechanism for defining and implementing such an Active Information Model and in doing so makes it possible to put the needs of the users of the information system in the center of the decision support process.
Problem Definition
FIG. 27 is an information flow diagram describing the operation of the Home Care organization. It identifies the specific roles within the organization as well as the forms that are used to communicate the information. Table 27-1 below is a summary description of these forms.
In general, the process starts with a verbal order from the attending physician stating that a patient may be discharged from the hospital and requesting that this patient is placed under home care. The Certified Coordinator at HomeCare verifies the patient's eligibility for home care under the patient's insurance plan and using an Intake Form (form 1) issues a request to a Registered Nurse to conduct an initial assessment of the patient's home environment. This assessment starts the process of providing the appropriate level of care to the patient as well as the billing authorization and payment process for HomeCare.
The process of home healthcare is a supervised, regulated, collaborative process where actions and observations by professional caregivers are documented and used as a basis for future decisions. The information system that supports documentation and communication of this process must be reliable and easy to use while at the same time flexible to allow its users to execute their professional discretion as required.

TABLE 27-1

Forms useful in the system of FIG. 4.

Reference ID	Description

1	Intake Form
2	Dr Verbal Order
3/O	Open Reimbursement form
4/O	Open Treatment of Consent
5/O	Open Financial Responsibility
6/O	Open Oasis Form
7/O	Open Progress notes 2nd page only
7SN	Daily Progress notes Skilled Nursing
7PT	Daily Progress notes Physical Therapy
7ST	Daily Progress notes Speech Therapy
7OT	Daily Progress notes Occupational Therapy
7MSW	Daily Progress notes Social Worker
7CNA	Daily Progress notes Certified Home Health
	Aid
8/O	Open	485
9	Med sheet side affects
10/O	Medication list
11	Discharge Summary
12	CNA Plan of Care
13PT	Plan of Care Physical Therapy
13ST	Plan of Care Speech Therapy
13OT	Plan of Care Occupational Therapy
13MSW	Plan of Care Social Worker
14	MSW Plan of Care Social Worker
15PT	Initial Eval Physical Therapy
15ST	Initial Eval Speech Therapy
15OT	Initial Eval Occupational Therapy
15MSW	Initial Evaul Social Worker
16	Activity Sheet
17MSW	MSW orders
17	Interim physician's orders
18	CNA Supervisory
19	Misc. communication form
20	Revisit Form
21	Transfer Summary

Designing an Active Information Model
A change in level of automation within an organization is for all purposes a change in some of the organization's practices. In most real cases, if an organization is complex enough to benefit from having a computer based information system, it can only implement incremental operational changes. Furthermore, any significant operational change within such an organization will effect operation of all of the organization.
Given these two factors, the only realistic approach is to create an Active Information Model for the parts of the organization where a change in the scope of automation is anticipated. If we accept that continuous improvement is a desirable goal, it would follow that the most critical attribute of an Active Information Model for an organization is that it can maintain its overall integrity even though it is always only partially complete.
Since a change is a possible outcome of automation, it is reasonable to strive to establish performance measures that are independent of the organizational structure or the approach that is utilized in implementing automation. For example the efficiency of a caregiver in performing clerical and administrative work in the course of their duties is a valuable measure of improvement since external regulatory requirements impose a requirement that caregivers document performance of their tasks. On the other hand the speed by which the Certified Coordinator can assign a nurse to a case is not a useful measure since it is subject to internal agreements that do not have significance outside of the organization.
In designing an Active Information Model it is therefore necessary to identify an appropriate subset of the organization where such a performance measure applies. Such a subset for HomeCare is shown in FIG. 28.
This subset involves attributes that are identified in table 28-2, Attributes of the Measurable Subset of FIG. 28.


	Roles	Certified Coordinator, Registered Nurse
	Categories	Patient information, Caregiver information,
		QA Inbasket, Medical records
	Messages	Email, printout, fax
	Actions	SNOpen

In observing the current state of the organization in the context of this simplified model, it becomes evident that in the initial definition of the organization (FIG. 27) certain control mechanisms are implicitly enforced. These mechanisms need to be explicitly defined in order for automation to succeed. For example, the simplified structure highlights that a mechanism that would notify the Certified Coordinator that a case has been accepted by the caregiver is not explicitly identified. It is common practice in small organizations for such functions to be implicit as the same individual performs multiple functions. In the case of HomeCare the administrative support functions in the organization are also responsible for certain clerical aspects of the QA function, allowing that individual to monitor closure of case assignments. The actual information flow under automation is more accurately demonstrated in FIG. 29, QA function explicitly identified.
One significant advantage of implementing an Active Information Model in small increments is that it simplifies the validation process thereby accelerating closure. After a few prototype implementations, the following considerations were identified and incorporated into the design:

- It is necessary to provide a simple mechanism to change the way each Registered Nurse may utilize the services of the automated system. For example, some nurses may wish to continue to use paper forms for some or all of their charting needs while others may chose to use email and a laptop or a workstation that is on a local area network.
- Different individuals within the organization may perform administration of the Active Information Model. For example the Certified Coordinator may choose to modify their own data sources while the Registered nurses may choose to modify the content and forms of charts that they create.

Incorporating these considerations resulted in the model that is shown in FIG. 30, Using generic Roles and proxy Roles.
The overall logic of the diagram in FIG. 30 is outlined in table 30-1,
Logical Behavior of the Active Information Model
(a) The Certified Coordinator role creates a message containing patient and caregiver information. This message is sent to the Registered Nurse role.
(b) The Registered Nurses role constructs a message containing patient information is sent to the specific Caregiver who is assigned to the case. The diagram shows RN1 Proxy and RN2 local as two possible destinations for this message.
(c) RN1 Proxy is a local handler that contains delivery information about RN1 mobile. The proxy function creates an information packet and forwards it to its client RN1 mobile. In this case the information packet is an INTAKE form (MSWord document) and it is delivered as an attachment to an email message.
d) The information in the INTAKE form is used to create all of the forms that are used by the Registered Nurse. The Caregiver transmits these forms to the Inbox as they are completed.
Implementation
FIG. 31 is a schematic depiction of the Active Information Model using three instances of the Active Agent and two database tables. Each instance of the Active Agent represents a role within the Active Information Model and is tasked with receiving and sending the appropriate messages providing the appropriate mapping of the data fields for each message. The specific activity that is demonstrated is the SN OPEN action that causes the commands [defselect_table1] to map information from intake.mdb:table1 data base into appropriate format and the command [definsert_SNOpen] to select RN010 as the final recipient and present this information to the logical view of a “registered nurse” as seen by the Certified Coordinator.
The disposition of the message, i.e. the package in which the information is to be delivered to RN010 depends on the preferences of that individual. This package may be a facsimile, a print out, a phone message or a page. In this case the Active Agent instance that represents RN010, upon being presented with the SNOPEN action, creates an Intake form (an electronic document), populates it with the patient information and forwards it as an e-mail attachment.
The primary purpose of the Active Agent engine is to facilitate the implementation of an Active Information Model. For this Active Information Model to be effective its elements must deal with abstract information at the same level as the corresponding organizational elements. This capability is highlighted by the use of a reference to HCFA 485 form at the level of Active Agent instance “Registered Nurses”. Although the content and the disposition of the information are substantially at the discretion of the Certified Coordinator and the RN010, the overall performance of the generic role of registered nurse is a regulated issue. At the most pragmatic level, these regulations are enforced by the way the information regarding the care of patients is presented to the payers. If (and when) the structure of HCFA485 is modified, that abstract view of this change does not change the functions within the role of the Certified Coordinator.
Deployment
FIG. 32 demonstrate a practical deployment option for the Active Agent. Each individual within the enterprise is assigned a Personal Information Portal, which serves as the individual's agent within the enterprise information system. This approach simplifies the task of providing access to information services within the enterprise as well as the communication process between different professionals.
Implementation Detail
Certain aspects of the pilot implementation for the system are presented below for reference. This pilot implementation used a Microsoft Windows NT® operating system as an implementation platform. The role definitions were captured in simple binary files using “.ham” extension. The pilot implementation included additional caregivers and certain other elements of the Active Information Model that are reflected in the role configuration files below.
Conventions
A directory structure that is used in implementation of the system in this example is presented in FIG. 33. This implementation includes two database files (.mdb files) and six role definition files (.ham files).
A convention that is used in this directory structure is not required by the Active Agent Administrator Utility. However certain additional conventions are necessary for proper operation of the system and are outlined below:

- Roles are registered in the system registry under:

HKEY_CURRENT_USER.backslash.Software.backslash.Corybant.backslash.H-armEng.backslash.Roles
This is accomplished by using the “Register” button from within the Active Agent Admin tool under the Role tab. If a role configuration file (.ham file) is being installed, this step is necessary to “introduce” this role to the operating system. Note that this convention enforces a need for unique names for each role within an environment.

- The role definition files specifically identify the data sources that they use. These categories include the database tables, other role definition files (.ham files), and other data sources for which a provider is available (see Adding a new category below). A new data source can be identified by specifying a path or by identifying a data source that has been registered with the system. The convention that is used in this implementation is to register ODBC data sources as a system DSN under ODBC control panel.
- Location of MSWord® documents that are created from within a role configuration file (.ham file) are specified in the ham file to be in the directory that is associated with that role. For example the role rn030 creates multiple forms upon receipt of GENPAC command. These forms are created as Word documents inside the directory Program files.backslash.Corybant.backslash.homecare.backslash.registerednurses.ba-ckslash.rn030
- Templates for MSWord® documents that are used as datasources are stored with other MS Office templates. The Active Agent engine enforces this convention.

Data Sources
The following table summarizes the datasources that are specified in this example.


Name	Type	File	Description

cg	Access table	. . . \homecare\homecare.mdb	Care giver database. This
			table is references by the
			Intake form that is a part of
			the Intake.mdb database.
Table1	Access table	. . . \homecare\Intake.mdb	Patient database table. This
			table is populated via the
			Intake form that is part of
			the Intake database
Intake	WORD	Intake.dot	Intake form that is created
	template		by the proxy role
			configuration file (.ham file)
			associated with the caregiver
			who is assigned the case.
			This form is mailed to the
			mobile caregiver.

Role Configuration Files
FIG. 34 illustrates Role Configuration models for the local Network.
FIG. 35 illustrates Role Configuration model for Certified Coordinator.
FIG. 36 illustrates Role Configuration model for the mobile caregiver.
FIG. 37 illustrates Role Configuration model for generic RN role.
FIG. 38 illustrates Role Configuration model for a mobile RN role.

Claims

What is claimed is:

1. A service support system, comprising:

one or more computerized servers each coupled to one or more digital memories and to a network;

software executing on individual ones of the one or more computerized servers from a non-transitory medium;

one or more rule sets stored in one or more of the one or more digital memories;

a plurality of interaction ports enabling two-way communication between the one or more computerized servers and individual ones of a plurality of different sorts of computerized communication devices using one or more of voice, text, email, and interactive display interfaces provided by the one or more servers; and

instantiation and configuration functions accessible by users of the computerized communication devices, the functions to instantiate and configure active agents;

wherein a user accessing one of the one or more computerized servers is enabled to instantiate and configure one or more active agents dedicated to the configuring user or to another user, the one or more active agents to have functions for accomplishing tasks for the user to whom the active agent is dedicated, including accessing network-accessible data and returning said data to the user, and wherein the configuration of one or more active agents dedicated to a user provides a Personal Information Portal (PIP) wherein accessing the PIP by the user to whom the PIP is dedicated initiates one or more tasks performed in conjunction with the one or more rule sets.

2. The service support system of claim 1 wherein the different sorts of computerized communication devices include but are not limited to, land-line telephones, smart telephones, digital pad devices, network appliances and laptop and desktop computers.

3. The service support system of claim 1 wherein the tasks that are enabled to be performed include establishing, conducting and terminating communication with other PIPs, and with network-connected data repositories.

4. The service support system of claim 1 wherein a PIP comprises at least one defined role for the dedicated user, the role defining nature of tasks undertaken on behalf of the dedicated user.

5. The service support system of claim 1 wherein interaction between PIPs active agents and Rules provide for matching one or more services with individual users as recipients of such services.

6. The service support system of claim 4 wherein roles include administrator, service provider and object of services.

7. The service support system of claim 1 wherein the PIP is configured with dedicated persistent storage.

8. The service support system of claim 7 wherein the PIP comprises functionality for storing data and functional activity over time.

9. The service support system of claim 1 further comprising an interactive interface enabling a user to whom the PIP is dedicated or an administrator to edit characteristics of a PIP.

10. The service support system of claim 1 wherein one or more active agents may be instantiated in a manner that the agent expires when its tasks are completed.

11. The service support system of claim 1 wherein an active agent is enabled to trigger events through other active agents.

12. The service support system of claim 1 wherein a PIP has functionality for amending its active agents over time.

13. A service support method, comprising:

instantiating one or more active agents dedicated to a user in a Personal Information Portal (PIP) operating on a network-connected communication device through one or more of voice, text, email, and interactive display interfaces, the one or more active agents having functions for accomplishing tasks for the user to whom the active agent is dedicated, including accessing data and returning said data to the user or to another active agent;

coupling the PIP with other PIPs dedicated to other users and to one or more computerized servers each coupled to one or more digital memories storing rule sets and to a network, the one or more servers executing software from a non-transitory medium; and

initiating and performing specific tasks for the user enabled by functionality of the one or more active agents.

14. The service support method of claim 13 wherein the network-connected communication devices include, but are not limited to, land-line telephones, smart telephones, digital pad devices, network appliances and laptop and desktop computers.

15. The service support method of claim 13 including steps for establishing, conducting and terminating communication with other PIPs, and with network-connected data repositories.

16. The service support method of claim 13 including defining specific roles for different users, the roles constraining nature of tasks undertaken on behalf of the dedicated user.

17. The service support method of claim 13 including steps for matching one or more services with individual users as recipients of such services.

18. The service support method of claim 16 wherein roles include administrator, service provider and object of services.

19. The service support method of claim 13 including configuring the PIP with dedicated persistent storage.

20. The service support method of claim 19 including steps for storing data and functional activity over time.

21. The service support method of claim 13 including steps for editing characteristics of a PIP through an interactive interface.

22. The service support method of claim 13 including steps for instantiating one or more active agents in a manner that the agent expires when its tasks are completed.

23. The service support method of claim 13 including steps for an active agent to trigger events through other active agents.

24. The service support method of claim 13 including steps for amending characteristics of active agents over time.