TIHI NSF Abstract for Challenge Grant PI meeting, 20-22 March 1996

17 March 1996, updated 15 April 1996, 15January 1997.

Trusted Interoperation of Healthcare Information (TIHI)

XiaoLei Qian; Gio Wiederhold, Michel Bilello, Andrea Chavez, Vatsala Sarathy, Xin Yu and Chris Donahue.

SRI International; Stanford University; and Oracle Corporation
qian@csl.sri.com; gio, bilello, andrea, dewi@db.stanford.edu; vsarathy@us.oracle.com

Abstract

The TIHI project addresses the issues that arise when some information must be shared among collaborating, but distinct enterprises. Such enterprises cannot fully share their data and information resources, although some information exchange is essential. The TIHI model deals then with the protection of shared information among friends, rather than with the withholding of information from adversaries. Protection of information interchange can also be neccessary within a single enterprise, when authority and responsibilties differ significantly.

It also deals with a specific gap which exists in the current model of authentication, authorization, information access, and presenting the resulting information to the requestor. In most practical domains there is no guarantee that the partitioning used for access will match the partitioning used to organize data for storage and retrieval, unless a very simple model (say open, secret, top secret) is used and rigorously employed. The unique aspect of the TIHI approach is that it also checks the results.

Problem Definition

We define domains as areas where data can be freely exchanged, and hence focus on exchange of information among domains. Among collaborating domains information exchange must controlled, auditable, and effective. Examples of domains that must collaborate to satisfy business needs are

To satisfy the access needs while protecting information outside of such collaborations researchers and legal authorities define complex configurations of access rights, say for physicians to their own patients, for nurses to the patients in their ward, for medical researchers patients in a specific disease category, and for billing personell information of limited medical depth. These access rights form a complex web, which does not match the capabilities of the record systems used to enter, store, use, and maintain the information. It is nearly impossible and certainly excessively costly to divide all the information in a medical, manufacturing, or even military domain into cells that are unique to one specific combination. The number of cells would approach the product of all the category sizes. Preventing an occasional misfiling would also be an enormous burden for the data-processing organization. TIHI deals with this problem by checking the retrieved result after access and before presenting it to the user.

Domains may encompass multiple databases and computing systems, or can cut through such systems if adequate protection can be maintained within such systems. Our technology defines intelligent gateways, or security mediators through which all communication among domains is channeled. Domains may be protected by multiple security mediators, especially if there are interactions with other domains of differing flavors. A security mediators is owned by a security officer, who has the authority and responsibility to enforce the security policy set by the enterprise for its domains.

Setting

We assume that security mediators operate in a secure environment: While these three conditionss are still a topic of current research, much progress is being made and adequate solutions exist for many practical settings. Adequate in practice also means that there is a reasonable balance between cost and effectiveness.

Architecture

The TIHI system concept provides a gateway wich mediates both external customer queries and all results generated in response to any queries. This security mediator applies the rules which define the institution's security policy, and if no rule applies, refers the communication to the institution's security officer. The security mediator is composed of a computer workstation, its software, communication linkages to the interanl domain and the exteranal world, and a human who takes responsibility. The system is best visualized having a protected domain, protected by a security fence (a firewall) from arbitrary access. The only access into and out of the domain is via a distinct workstation, operated by the security officer. Within the workstation is a rule-base system which investigates queries coming in and responses to be transmitted out. Any query and any response which cannot be vetted by the rule system is displayed to the security officer, for manual handling. The security officer decides to approve, edit, or reject the information. An associated logging subsystem provides both an audit trail for all information that enters or leaves the domain, and provides input to the security officer to aid in evolving the rule set, and increasing the effectiveness of the system.

Figure 1. Domain Model.

Important aspects of the TIHI approach are

For information retrieval, obtaining related, unexpected information is a bonus, and of high value. For protection, it can be disastruous.

Policy Support

The TIHI design permits an enterprise to set a wide range of policies

Source Access

The queries are translated into operation over views. When relational databases are used, these views will be effciently compilable. Other files can only support a single view. Conventional mediator technology can be used or invoked to deal with heterogeneous resources within a domain.

The security mediator may also keep passwords to domain resources in encrypted form. Decryption requires a password to be submitted by an authenticated customer. Keeping domain password within the mediator avoids their dissemination into environments that are not secure, and permits selected denial of access to customers when their authority changes.

Note that even an empty, rule-less, security mediator can greatly improve operations. Without rules all interactions are presented to the security officer, but they are now viewed on-line, and immediatly editable, if needed. In time simple rules can be entered to reduces the load on the officer. Current, paper-based systems often take weeks for turn-around, or are bypassed.

A reasonable goal is the automatic processing of say, 90% of queries and resulting responses.

Figure 2. Coverage of Access Paths.

Summary

TIHI addresses a issue in the protection of information that is starting to arise as the basic infrastructure for secure transmission and storage enters into practice. It assume an environment where encrypted transmission, firewalls, passwords, and private and public keys provide adequate protection from adversaries. The problem which remains is to enable selective sharing of information with collaborators, without the risk of exposing related information in one's enterprise domain that needs to be protected. Such protection is being provided by a rule-based gateway processor, under control of a security officer who now can implement the policy that is set by by the enterprise to protect its domains.

It is obvious that the problem and our solution applies not only to a healthcare setting, but is equally valid among collaborating manufacturing enterprises and in many military situations. Focusing on the healthcare setting permits us to investigate the adequacy of the systems and its primitives with respect to requirments that a re now being formulated. Early availability of protection technology can help in providing feedback to people faced with formulating and implementing policies to protect privacy and confidentiality.

Status:

The current state of the TIHI project is:
  1. Requirements, specifically with respect to model legislative codes for the protection of healthcare privacy have been analyzed.
  2. An overall design of the TIHI architecture has been completed.
  3. The problems and complexity of view access and interaction have been analyzed, and conditions for secure operation are being defined.
  4. A simple prototype of a security mediator is operational. It accesses remote resources through a TCP/IP connection. Customers will access the security mediator through secure Netscape (tm).
  5. A rule format has been defined which should be clear and manipulable by a security officer who is not a computer specialist.
  6. A simple rule interpreter has been implemented which allows these rules to be applied to queries and responses.
  7. A initial set of primitives has been defined that are needed to support these rules. These must still be validated vis-a-vis the requirements being produced.
We are starting the integration of the software modules and expect to have a version which permits demonstration of the TIHI concept by the summer of 1996. We have also submitted an initial paper for a security workshop.

Other TIHI material.