Given the business and technical requirements in the previous sections, this section introduces some of the basic design principles to be used to arrive at a technical solution.

The connectivity and reach requirements of the network imply that a cost effective solution cannot rely on a new network infrastructure being laid for the specific purpose. Private networks are inherently expensive to setup as well as to maintain. Hence, the solution proposed must work across the readily available internet infrastructure, but still provide the necessary measures for providing privacy and security.

This means the solution must use internet protocols such as web services over HTTP/S (Hyper Text Transport Protocol over Secure Sockets Layer) to communicate between the different nodes in the HIE/RHIO.

In a networked system of RHIO and provider nodes, it is not always possible to ensure that all the nodes will be available at all times. This is especially the case with nodes that are deployed at physician or hospital sites. In order to provide reliable communications between these nodes, the system should implement a reliable messaging infrastructure to handle intermittent outages of different nodes at different points in time.

The scale requirements of the HIE/RHIO call for a distributed model of operations and deployment. On the other hand, there is a definite need to retaining a central repository for enabling patient lookups and also maintaining core longitudinal information for availability purposes (e.g. when you need key health information about a patient in the ER, the access needs to be fast). In order to satisfy both requirements, the system will contain services both at the central (RHIO) level, as well as enable different participating peers to communicate directly with each other. By encouraging peer-to-peer (a.k.a. distributed model), yet also supporting a centralized model seems like it will get us the best of both worlds.

The healthcare network, once deployed will be an “always-on” solution. As more and more providers start relying on the system, it becomes mission critical and will not withstand outages or downtime to accommodate deployment of additional applications.

Hence the platform must allow for centralized control over the deployment and maintenance of the different applications deployed on it. This means each RHIO may at any time decide to deploy additional applications as and when they are developed and certified, and these applications should be dynamically provisioned or sun set without any downtime to the component nodes.

The system should enable a predefined set of integration and interaction patterns* that allow for third party vendors and agencies to create certify and deploy new collaborative applications. These patterns need to be documented, reference implementations made available to prospective developers and a certification and testing process put in place to validate them.

* A pattern is fully specified reusable integration and interaction model that can be reused repeatedly. E.g. “Request-Response” is a pattern where a client requests for some service to be performed and the server responds with a response when the processing is completed.