National RHIO Services (NRS): Certification Authority (Root Certification Authority)

This node is a secure service that is hosted centrally on the internet. There is exactly one virtual instance of it for the entire NHIN. Physically, this is built with redundancy, fault tolerance and high availability. One could think of the national RHIO services to be analogous to the root Domain Name Servers that serve the functioning of the internet.

It enables discovery, coordination and secure communication between the RHIO root nodes (shown as RHIO network services in the diagram). This contains a RHIO lookup service that can be used by RHIOs and HIEs to find and communicate with other RHIOs and HIEs. It is a RHIO registry of sorts.

It contains the infrastructure for issuing Certification Authority (CA) certificates (aka subordinate CA) to RHIOs and HIEs. The RHIOs and HIEs themselves will use this as their certificate to issue server certificates to end Nodes.

The number of services running at the national level is simple and few. This keeps the design simple yet effective. Let’s follow the principle of parsimony for its obvious benefits.

Regional RHIO Services (RRS)

The RHIO wide components are deployed at this node. They can be broadly classified as: Indexes, Search services, Authentication and verification, Communication enablement, Directory and Gateways to other networks and centralized collaborative applications. We will describe each of them below.

Indexes: The most commonly required index is the RHIO wide patient index (also known as the Network Master Person Index NMPI). This index maintains pointers to provider nodes where data about a particular patient exists. Each patient has a group of pointers. Due to the inherent non-deterministic nature of patient matching, there is potential for duplicate groups existing for a given patient. There is also the potential that groups can be formed with erroneous matching. The index maintenance involves a combination of automated and manual maintenance tools and procedures.

Search services: This service helps you search through an NMPI (Network MPI) for matches. There are sophisticated matching and searching algorithms developed by HealthUnity that forms this service.

Authentication and verification: It is incumbent on a RHIO to ensure that only after full identity verification, communication nodes (i.e. physician practices, hospitals, labs etc) are permitted to join the RHIO (in a technical and business sense). A RHIO will also have its own user agreement that stipulates the business and contractual obligations. The technical service run here is the CA (certification authority).

Communication enablement: In a dynamic RHIO network, it is to be expected that nodes will join, may leave, may be removed or suspended due to various reasons. In such a dynamic environment, the communication enablement service will ensure that any node wishing to communicate with another node will be able to do that with guaranteed security, delivery and privacy.

Directory services: The directory service provides a rich, multi-attribute, multi-level, multi-entity managed service. There are many subdirectories such as physician directory, facility directory, RHIO directory and system meta-data services (e.g. to query about what services are provided by a given RHIO). We will need to decide on the exact subset of services that would form the national standard keeping the principle of parsimony in mind.

Gateway Services: In a “network of networks” model that we live in today, it is imperative that we leverage the preexisting networks and interconnect with them. E.g. RxHub has a network that connects with major PBMs (Physician Benefits Managers). SureScripts has a network that connects to many of the nation’s chain drug stores. LabCorp is a major lab vendor who has a centralized gateway for lab ordering and results delivery. The gateway-services enables the specific communication between the RHIO network and a given 3rd party network.

• Lab Provider Gateway

  This node contains the gateway to laboratory service provider applications. The interfaces to these gateways are standardized to enable any lab service provider to accept lab orders and to return lab results to the RHIO nodes. (e.g. LabCorp). HealthUnity is in the process of building such a gateway (work in progress).

• Data Surveillance Gateway

  This node represents the gateway to standardized data collection applications that are provided with de-identified information through well known interfaces. These applications may then choose to use the de-identified information for performing analyses that enable bio surveillance, adverse drug event studies etc.

Again, keeping the principle of parsimony in mind, we believe the above are a minimum set of services that will be required to be provided by the RHIO Regional Services instance.

Nodes

A node is typically deployed at each of the provider practices. The nodes enable the communication between entities (such as a hospital, a physician practice, a lab etc). The nodes make use of the services provided by the Regional RHIO services in enabling health information communication. The nodes provide a set of services that can be largely classified under the following heads:

Indexes: Patients belonging to the local provider are indexed at the RHIO level and cached at the node level for fast access.

User Management: This provides the ability to manage users and the roles they can play in the system. Note the federated model we are proposing! There is no centralized user registration required. Every node by itself makes decisions on who can join in on the network. This also lets the RHIOs and HIEs determine membership criteria and enforcement. By providing a decentralized model, we enable greater empowerment and better acceptance from the RHIOs and HIEs to adopt the NHIN architecture. This will also help existing RHIOs and HIEs to join in on the NHIN.

Back-end Application Adapters: These adapters enable the integration of the NHIN use cases with the backend applications that provide data and consume data. One should leverage HL7 (and MLLP) as existing standards. The CCHIT Interoperability committee is working on certain standards that we believe over the longer term make it easier to connect to back-end applications. As for all the current breed of applications in production, we will have to solve them one by one. HealthUnity has gained tremendous experience by building two adapters in the last nine months (to Practice Partner from PMSI, which is an integrated practice management and EMR & MediTech Hospital Information System)

Management Client: This is a light weight application that helps manage the various functions offered by the nodes to the internal applications. E.g. it is quite conceivable that a NHIN aware EMR application will be able to use the services of the use cases supported by the RHIO (and by extension the NHIN) and hence the management client may seldom be used.

Auditing and logging: The auditing and logging infrastructure provides auditing of all actions and logging of events. This helps enforce user and system actions and help comply with HIPAA and various state laws.

Access control and policies: Access control describes how data stored in the node will be permitted to be accessed. The publication, accept and subscribe policies determine how sensitive data will be handled.