The following is a summary of HealthUnity’s proposed architecture for healthcare information networks (HIEs and RHIOs). For a copy of the detailed document please request the “Model Architecture for the National Health Information Network” whitepaper

Click here to request the whitepaper

An HIE, by definition, enables the exchange of data between two or more clinical systems. These systems can communicate via an intermediary, say a central repository, or directly through some form of secure introduction. We will discuss a true peer-to-peer communication and collaboration network model that enables different participating entities to exchange information with one another in real time. In this scenario, a set of services deployed centrally enable the co-ordination of the network's nodes. Both the centralized and peer to peer use cases will work side by side on a secure infrastructure that leverages the internet.

Network Services for RHIO

At the network level (meaning at the RHIO level), the HIE is comprised of a centralized set of services, collectively referred to as the Network Edition Services. These services include RHIO support services as well as a centralized set of network management and information services. Among the different services that are available at the network level are:

• Master Person Index and Search
• A set of ancillary connectivity services that serve as the gateway between the RHIOs and HIEs and entities. e.g.
• Lab services
• Radiology Services
• ePrescription services
• The Physician Master Index or the Global Address List of physicians and other addressable entities
• Patient interaction services (Personalized Portal Services)
• Systems management and monitoring services
• Auditing services
• Data Collection and Analysis Services (e.g. Outbreaks, Adverse Events, Bio-Surveillance)
• Centralized data transformation and cleansing services
• Security and authentication services
• Node provisioning and de-provisioning

Hospital and Physician-practice Services

For the HIE / RHIO to interconnect the practices and physicians with the network there is a need for a component of the system to run at the individual hospital/practice level, providing the following services:

• Authentication and authorization of users
• Providing a federated model of administration
• Performing auditing and logging functionality in a scalable manner
• Providing clinical collaborative functionality to end users
• Providing a local person index to enable mapping the different patient identities in disparate clinical systems deployed at the practice
• Providing a conduit of information from the practice level information systems to the network where necessary
• Providing the application layer for client applications to interact with the system
• And isolating the internal applications from having to directly deal with the security and scalability requirements for dealing with the outside world. Keep in mind that the internal applications are not designed to be accessed over the Internet by dozens of additional users.

To this end, at the provider (hospital as well as practice) level, the HIE / RHIO deploys a set of components and services. In a large hospital setting, this is deployed as a specialized hospital version of the HIE peer server and at a small practice, this is deployed as a scaled down version of the same peer server.

Client Application

HIEs typically provide a client application which is used by practitioners and hospital staff to interact with the system. This client enables staff and practitioners to perform searches for patients and retrieve and view patients’ demographic information. It also provides the user interface through which the various use cases show up as collaborative workflows.

An advanced form of the client is a Windows based client application (a smart client) that enables authenticated users to perform authorized operations on the HIE / RHIO network. The client application also exposes a robust mechanism to administer roles, users, as well as perform configuration activities on the local practice. The client connects to the appliance through Secure Sockets layer technology and thus acts essentially as a smart web browser with rich UI. All of the major activities performed through the client application are controllable and assignable to any particular group of users through role-based privileges. For example, a certain set of users designated as front office staff may be prohibited from viewing protected patient information.

Network Management Node (at the HIE / RHIO level)

This component of the system provides primarily those services that manage and maintain connectivity between other nodes in the system. These include the following:

• Node Registry
• Provider Registry

Node Registry

This is an infrastructural service that is deployed at a central location, which keeps track of each of the HIE / RHIO network nodes as well as the practice level nodes in the system. This enables any node in the system to perform a lookup for any other node in the system.

Since nodes in the practices are not always guaranteed to be available on the network, and since the broadband connection available at some small practices are not guaranteed to have a static IP (Internet Protocol) address, special care is taken to ensure that the system withstands such changes in addresses at each of the nodes.

Provider Registry

Clinical collaborative applications developed for the HIE network require physicians to be able to find and collaborate with other physicians in the network. For that to work, HIE’s and RHIO’s typically maintain a Provider registry at the network node which allows lookups for physicians in a reliable manner.

This registry will have the following attributes:

• Global address list of all physicians registered within the scope of the HIE/RHIO
• Ability to refer to physicians by either UPIN or NPI
• Ability to create and maintain address entries for non-physician entities such as labs, pharmacies, wards etc.
• Access to modify this registry will be restricted to HIE/RHIO authorized personnel and the actual modification of this address book performed through a predefined process of verification before any updates are done.