This paper was written after it became clear that the consortium needed a new vision of what was required to satisfy the underlying requirements of a health information network.  This article was written, in late  August of 1996,  shortly after Netscape deployed the first implementation of SSL 3.0.  The singular importance of SSL3.0 was its ability to support strong client authentication with digital certificates.  This provided the the healthcare community with a inexpensive and scalable mechanism to support secure communication, over the public Internet, with a large community of authenticated users.

The Hdinet Registry, as described, was engineered but never deployed.   This particular Registry model assumes a high degree of cooperation between industry participants.  Unfortunately, financial support for the project was withdrawn before advocates could create sufficient industry buy-in to this project.   To some degree, the HCFA "Internet Ban" was responsible for the project's demise.  HDInet's major financial backing came from large California healthplans; when HCFA published its  "no Internet" ban in October 1997, many supporters within the plans withdrew from this aggressive Internet project.   Arguments as to erroneous assumptions in the of the HCFA position would not be heard by those at risk to HCFA recrimination.

There are more realistically achievable  models of this sort of health care Internet Registry than that proposed here.  The Tunitas Group is working today with selected plans and providers to implement such models and accomplish the implicit goals of the original HDIC effort.   For more information, send us an eMail or call.

As an industry initiative, the Healthcare Data Information Corporation (HDIC) is committed to improving the processes for electronic exchange of health information.  HDIC’s efforts exist both at an application level to create solutions for specific data sets and at an infrastructure level to develop an open and widely available communication medium appropriate for healthcare data.

HDInet is the principal mechanism by which HDIC will establish and manage the broadest connectivity into the California healthcare community.  HDInet at this level is infrastructure and is distinct from the process by which applications are created and managed.  Immediately, HDInet will described as a "virtual Intranet"; this document will describe: the HDInet architecture and its principal software component the Registry, how application content is developed for HDInet, and the implementation issues for HDInet.

This section details a proposal for the construction of HDInet as a "virtual Intranet" using the public Internet for transport.  HDInet  would include resources owned by HDIC members and their vendors and an HDI Registry which would manage access to those resources.  The Registry defines HDInet in it provides directory services to identify and authenticate all users and resources.

HDInet was originally conceived as a "private" healthcare only network with a transport backbone that would be "physically" distinct from any other network.  In such a vision, the healthcare network would be "protected" by its "separation" from other computing resources and networks.  This sort of thinking is generally at odds with the requirement that the network be cheaply and broadly available.  Further, in recent months, the development of SSL 3.0 ("secure sockets layer") protocol for authentication and message encryption has greatly enhanced the possibility of wide scale secure use of the Internet.  SSL 3.0 describes a "handshaking" process that uses digital certificates and public key cryptography to authenticate the user to a server and the server to the user and then create and exchange a one time symmetric "session key".  This session key is then used to "bulk" encrypt messages exchanged between the user and server.  These procedures, while not sufficient, provide the basis for the healthcare community’s secure use of the Internet.

A second concern motivating the design of a healthcare specific network was an requirement for guaranteed "acceptable" network performance.  Demand for Internet bandwidth has exploded; healthcare users may not be able to "compete" for bandwidth.  This was understood as an argument to construct HDInet as a private internet.  This thinking is "wrong headed".  Bandwidth issues should be a matter of economics; performance guarantees are be a matter for negotiation between users and their Internet service providers (ISPs).  HDInet users should be able to acquire the bandwidth that their business processes require and cost justify.  If HDInet were a private network, then users of time insensitive applications or those with limited bandwidth requirements would be "buying more than they need" and thus underwriting the costs of large institutions or other users with high bandwidth or time critical needs.  Since connecting the "small provider" is a primary requirement of HDInet, then, for economic reasons, HDInet should use the public Internet for transport.  Further, as the Internet becomes increasing integrated into everyone’s business, it will be even more difficult to cost justify a separate "healthcare" only internet.  This reasoning, however, does not preclude HDInet servers from being connected to each other by something other than the Internet.

Further, HDInet should be constructed with a minimalist philosophy.  The HDIC owned, managed, and or operated network components should focus on the very core of what is necessary to bring about the "HDIC vision".   HDIC should then use an RFI/RFP process to leverage those components to bring about specific applications.  In addition, a third party vendor program should be implemented to allow independent application developers to leverage the HDInet infrastructure in delivering high value information services to the California healthcare community.
 

HDInet Architecture Overview

The HDInet Architecture will be deployed as a healthcare industry "intranet" which will to a large extent use the public Internet for message transport.

The benefits of using internet technologies are clear as internet protocols and "browsers" are inexpensively supported by virtually every hardware and software platform.  The TCP/IP suite provides the best hope for a "lingua franca" for the healthcare community.  Further these technologies support recently developed techniques of three tier client server computing, in particular the use of the JAVA programming language.  An internet "browser" will provide a readily supportable interface to healthcare specific network applications written primarily in JAVA.

HDInet requires extensive directory services.  This directory should describe connected persons, organizations and resources (e.g. application servers, databases, mailboxes, etc.).  The descriptions themselves should be extensible and searchable on extensible criteria.  The directory services should manage not only descriptions and addresses but also permissions to access resources available through HDInet.  To enhance usability and security, the directory server should provide the HDInet user with navigation assistance in the form of a directory view that shows only the services to which s/he has access.

This architecture includes a "Registry Server" which provides these directory services.  This includes an object database which stores "arbitrarily complex" person, organization and resource objects.  It includes permission objects and certificates.  The Registry database and applications would be the only unique HDInet software infrastructure components.

For an industry as diverse and fluid as California’s healthcare industry, creation and maintenance of such a directory is a significant challenge.  Consequently, HDInet should distribute this maintenance as much as possible.  User and organization "objects" would be created by a user registration process which itself can be distributed.  Persons would be issued "digital certificates" as part of registration.  Creators of resources grant access "permissions" to those resources.  As part of the grant, the grantor may extend to the grantee the privilege to extend permission to other persons or organizations.  The grantee can then extend access to it’s subsidiaries or affiliates.

The HDI Registry also provides the HDInet user with navigation assistance in the following way: A Registry application presents an authenticated user with an HTML document where all the HDInet resources to which that user is permitted access are "pseudo hotlinked".  When a user selects one of these links, the Registry application assumes responsibility for communicating the user’s access privilege to the selected resource.  There are several models of how this may occur.  Easily understood is a process whereby the Registry application provides a limited duration digital certificate to the user.  This certificate is signed by the Registry, bound to an existing public key of the user, and includes extensions that describe the source of the user’s access privilege.  This digital certificate is then used to authenticate the user to the resource as part of the SSL negotiation.. The resource need only confirm the timeliness of the just issued certificate and note the user’s identity and the source of privilege.  In this way, the HDInet Registry manages the acl ("access control list") for the resource and all resource use can be authenticated.

HDInet may require resource owners to include some special functionality in their servers for which an API would be provided, but no requirement can made of the user’s browser beyond the ability to interpret Java byte code and support SSL 3.0.  The lack of custom software at the user’s site is critical to HDInet’s scaleability.

HDInet becomes "deployed" when the HDInet Registry is first available on the World Wide Web, the first users and resources are described in its database, and resource permissions granted.  The resource list will grow as HDI creates those resources that are of industry wide importance through an RFI/RFP process.  This process has begun with an RFI for a "healthcare enrollment" application and continues with an RFI/RFP for a "small provider EDI solution". Additionally, HDIC has outlined a marketing program by which it seeks to attract independent application development to serve additional community need .
 

HDInet Applications

This approach to HDInet separates the network architecture from healthcare applications so that the infrastructure can be deployed independently of application development.   With this approach, the HDInet infrastructure provides no value to the network user other than a searchable view of its directory.  [Note, though, that these directory services have substantial end user value.  At the very least, such a directory greatly simplifies eMail within the healthcare community ].  The applications that motivate connectivity to HDInet are still to be developed and deployed.  There are two processes by which these applications are created, an RFI/RFP process and a 3rd Party Vendor program.

HDInet Services that Support Independent Applications

The Registry identifies the application to users who have been granted access to that application.

The Registry authenticates users and enforces the access policies of a resource owner.   [Note: A user interacts with a "resource" through an "application".]   The application provider then need not maintain a "complete" access control list and need only manage the "permissions" that it has given.  For example, the application provider may contract its services to an IPA; the Registry allows the application provider to be insensitive to how the IPA re-distributes access to these services.

While managing this authenticated access, The Registry, will create some sort of a "nonce" such as  a serial number for a one time, short lived certificates.  This nonce is a unique number which can be logged along with user identification, resource, data and time.  This 5-tuple provides a complete log of resource utilization and can validate the application provider’s billing. HDInet should include a billing application to support a unified billing for all services and application utilization obtained through HDInet.

HDIC RFI/RFP Process

There are some HDInet applications that will result only after considerable specification by HDIC workgroups.  These are applications which either must operate in some workgroup defined way, interact with some HDIC resources; or for which HDIC members, in common, wish to encourage development.  To bring about the required application development, the HDIC workgroup would first issue an RFI to a vendor community.  Learning from the RFI responses and after defining appropriate business models for the application, the workgroup would then issue an RFP.

This process has been initiated for an ANSI X12.834 enrollment application and work has started on a ANSI X12.837 "small provider EDI" claims and enrollment application.

An HDIC community standard is clearly required by a longitudinal patient record and MPI; the workgroup RFI/RFP process will be utilized to create these applications.

3rd Party Application Vendor Program

HDInet relieves the provider of a network based application from the necessity of maintaining a network.  Additionally, the size of the HDIC community does attract tremendous software developer interest.  HDInet can capitalize on that interest by providing services of considerable value to those developers:

1.  Distribution. HDInet defines a market of connected users with a common interface to network applications.  If that developer or service provider adopts a "three tier client server" computing model, then HDInet can be the distribution channel for that vendor’s software products and services.  In particular, the vendor would use Java applets to create an interface to its network based applications.  Additionally, the vendor could also implement its applications with devices such as "plug-ins" but because such devices may be "browser specific" the vendor would subsequently reduce the scope of its potential market.
2. Marketing. HDInet can provide links to "information pages" or demo’s of vendors products.  In particular, the Registry would maintain "what’s new" pages describing new product offerings.  A vendor’s marketing might take advantage of HDInet’s distributive management model.
3. Customer support.  HDIC would provide for "customer support" for the basic user interface to HDInet (i.e. a browser and the HDI server navigation assistance).  The application vendor would only have to support its high value application and can assume connectivity to its application.
4. Billing.  Application vendors would establish contractual relationships with each of their users.  The vendor would create a Registry "resource" and "grant" that resource to an organization with which it had contracted.  Then all access to that resource derived from that grant would be billed to appropriate organization.  HDIC would outsource a billing function to create a unified bill for HDIC members.

Interface to Legacy Applications

An HDInet interface to existing legacy information resources is itself an application.  The owner of this legacy would create a Web application that emulates whatever interface currently exist to this system.  Some general tools for creating such applications are now available.  Such a tool is provided by OpenConnect’s "Web Connect" product.  A SSL session is established between the application and a properly authenticated user that has been "granted" access to the legacy system. The user then interacts with a Java GUI to a 3270 terminal emulation running on the application’s web server.  The application server then uses SNA to hook up to the host mainframe and access CICS, DB2, or any other IBM legacy application.  The Web Connect product is inexpensively (<$1000) available "off the shelf".

HDInet Implementation

HDInet is implemented by a HDInet web site providing the HDInet Registry applications with links to vendor provided applications.  These vendor provided applications would use an HDInet server API as required to take advantage of the Registry access control functions.  Both the Registry and any associated server API require custom development.  HDIC will seek a single source for these software components.  HDIC will solicit the interest of potential developers of these components in the first quarter of 1997 and expects to contract with one such vendor in the Spring of 1997.

HDIC would be required to acquire the physical infrastructure to implement the Registry WWW site, in particular a high bandwidth connection to the Internet backbone, routers and some server boxes.  The high bandwdith connection could be acquired by co-locating the Registry server at an ISP’s site.   HDInet’s  operating costs could be reduced if its Registry server were co-located at one of its member’s data centers.  Such co-location would require a static and registered IP address for the HDInet server.  The member’s Internet connection may have to be upgraded to handle the additional network traffic.

The traffic between the HDInet Registry server and either HDInet users or the application servers associated with resources does not involve high bandwidth transmissions.  All the HDInet user receives from the Registry are fairly simple HTML pages, an SSL negotiations, and perhaps limited duration certificates or other "tickets".  The application server will receives from the Registry only SSL exchanges and perhaps limited duration certificates or simple SQL gueries.   These digital certificates are small files on the order of 1K bytes.  The high bandwidth requirements of applications with medical content involving, say display of radiological images, do not involve the HDInet Registry servers.  These high bandwidth requirements would have to be satisfied by the ISPs of user and server and supported by the business processes of the net user and resource owner.

Note:  The term Intranet has come to mean something different than its orginal meaning as an internal network of "identified users".  In today's parlance, an Intranet is the portion of a corporation network that resides behind firewalls.  HDInet would not be considered an Intranet by today's meaning.

Note:  Today, there exists a commerical product offering that implements many of the access control ideas underlying the "virtual intranet" network model.  The getAccess Registry by enCommerce has the capablility of distributing access control and authorization in support of very large extranets (as many as 100K users).  This product is very cost effective and well worth consideration.