HomeSite MapProduct & ServicesTechnologyCompany ProfileLinks
Health & Technology

Information Technology

2017, Health Network
International, Inc.,
All Rights Reserved.

Site Map
Products & Services
Company Profile


Talk To Us

Technical Overview

The common thread running through HNI's software is the concept of "intelligent interaction".  HNI is building or acquiring a general-purpose set of software components for conducting interactions with end-users.  These interactions range in complexity from simple, question-and-answer surveys to complex, rule-directed web-based sessions.  In each case, a dialogue is conducted, in which we gather facts from, and supply feedback to, the user.

HNI's Web development platforms are Microsoft's Internet Information Server (IIS), Active Server Pages (ASP) and MacroMedia Flash.   Software applications are structured as a collection of object-oriented components, programmed in Visual C++ and Visual Basic for the Windows environments.  Microsoft's ActiveX standard is employed for re-use of components across applications.  Relational DBMS's such as Access, SQL Server or any other dataset accessible through ODBC are used for persistent storage.  The component architecture of HNI's products makes it possible for them to inter-operate with third-party applications such as the Microsoft Office suite and specialized tools for telephony, call management, and messaging.  

Strategy for Health and Personal Service Tools

Information technology enables inexpensive, convenient modes of delivery for many health and service-focused, self-management capabilities.  HNI is developing interactive software systems to be accessed by consumers directly via kiosk, personal computer and fax.   The systems assemble and deliver customized solutions based upon an analysis and tracking of an individual's unique situation and needs at different points in time.  Information about the consumer will be tracked over time, so that progress toward goals can be measured.  The systems' ultimate objectives are twofold: 1) to enable the consumer to quickly access information and resources to better manage personal and health-related problems; and, 2) to provide organizations with cost-effective means to support their employees and help them better balance work/family responsibilities.

Systems' Architectural Vision

This long-term architectural vision supports the generalized model of intelligent interaction with consumers.  The principal components of this architectural vision are discussed below.  It is the framework within which all short-term systems are developed.

Interfaces. Users interact with systems via web-browser interfaces.  The web interface would support the full spectrum of multimedia content that commonly appears on web sites today, including audio and video.  The systems also send faxes or e-mail output to the user (e.g., to send reminders) or, if the user desires, to a "support" professional (e.g., to request appointments or follow-up calls).


In the above graphic we use the term counselors to denote the professionals that assist users in their use of the system, including technical-support operators as well as behavioral, financial, legal, and nutrition specialists, any of whom can join a session when the user asks them to.  At any time, the user should be able to press a button (either on the telephone or on a web page) to request assistance.  In a telephone session, a counselor would come on the line and would be able to see on his or her computer a transcript of the session thus far.  The counselor could then answer specific questions or even opt to conduct the remainder of the session verbally if the user preferred not to return to the self-directed mode.  In this case, the counselor would see on his or her computer a graphical version of the same questions that would have been asked by the system, and would enter answers on behalf of the user.  

During a web-based session, the user might ask for help by requesting a telephone callback, an Internet-phone conversation, or an on-line chat session.  The counselor would have the full context of the session available, and would be able to work collaboratively with the user during the remainder of the session, for instance by guiding him or her to a particular web page (i.e., by entering a web-page address or URL into the user's browser).  Again, an important goal of HNI's systems is the ability to conduct interactions using a variety of different interfaces, or even a mix of multiple interfaces.  The key to doing this efficiently is the separation of the logic of the interaction from the details of the interfaces.

Counselors might work out of a central call center, but it will also be desirable to enable them to work out of their homes or offices.  Such a distributed model would enable experts/specialists located throughout the country to be brought into sessions on demand.

Interaction Engine and Rules. The The Interaction Engine is responsible for guiding the interaction with the user, based on a database of rules that embody the system's methodology for tailoring solutions to individuals.  The abstract notion of an " interaction" in HNI's systems comprises the following concepts:

  • Facts need to be collected from the user.  
  • To collect a given fact, the system presents the user with a question or prompt.  
  • As facts become known, additional facts can be deduced from them.
  • When enough facts have been collected or deduced, an action can be taken.  

The list of known facts - for a first-time user - starts out empty, and grows dynamically as the session proceeds; at the end of a session, facts are saved in a database for use in the next session (see Consumer Encounter Repository below).  The prompts emitted by the system to gather facts can be as simple as questions spoken over the telephone or as complicated as entire web pages.  The actions are also most often intended to produce output, either spoken or page-oriented.  It is the job of the rules to specify how all these things are done - that is, to script the interaction with the consumer.  The script amounts to a large decision tree or flowchart.

A key design goal for the rules database is the separation of the logic from as many of the user-interface details as possible.  For example, the rules should be able to say " ask the user how old he or she is" , and not have to worry about whether this question is spoken over the telephone or displayed on a web page, or whether the user presses a telephone key, a radio-button on his or her screen, or speaks to answer.  

Another feature of the rules would be to prompt for a new fact implicitly, simply by referencing it.  For example, if the interaction is concerned with a topic for which the consumer's age is not relevant, no question about age should be asked.  But if a rule is encountered which depends upon age, the Interaction Engine should be able to ask about age without the rules having to say so explicitly.  Rules are specified using a specialized language.  The Interaction Engine will parse this language and use the resulting parse-tree to determine, at each stage of the interaction, what needs to be done next.  To do this, it will consult an in-memory database or "dictionary" of facts about the consumer that have been gathered thus far (see Run-Time Fact Dictionary below).

Run-Time Fact Dictionary. The rules concept discussed above makes reference to a number of facts about the consumer; these facts need to be learned and remembered as the interaction proceeds.  HNI's current software product implements an object-oriented run-time dictionary that serves as a repository of facts.  Each fact is represented as an object with unique properties, such as its data-type.  In the future, HNI will add a large new class of capabilities to the fact objects: each fact will be able to prompt the user for their values in a variety of different ways.  For instance, an object storing the user's name will be able to be told whether to use a text, audio, or HTML prompt, in English or Spanish, etc.  The rules will issue these prompt-configuration instructions to the objects in the dictionary as the interaction proceeds.

Content Repository. In addition to prompts for new facts, the rules language will provide statements that trigger the generation of output.  Both prompts and output will be constructed out of audio, textual, and graphical elements, or "chunks", stored in a relational database.

Consumer Encounter Repository. An important goal of the system is to support consumers over time as they solve personal problems, engage service providers, and work on long-term goals, and this obviously requires all the facts that are gathered about a person be available for use in subsequent interactions.  For the most part, this data will be simple numeric, Boolean, or textual responses to the questions posed by the Interaction Engine, and should be easily stored in a relational database at the end of each session and retrieved at the beginning of the next one.  The schema for this database will be designed to allow both consumers and advisory professionals to review the history of a consumer's interaction with the system.  In addition, advisory professionals will be able to analyze the data for an entire population.