As we described, HIE benefits accrue under five main heads : Quality of care, reduction in costs, improved patient experience, better compliance and access to new revenue sources. We will now turn our attention to describing the functional requirements of HIEs that are broadly universal. The requirements can be classified as either technical or business requirements.

The system should be secure and hardened to provide security of the information contained. It should withstand and thwart attacks from malicious and unauthorized use. Additionally, the system should require that any user interacting with the system is properly authenticated.

Given the scale of the system and the number of users potentially logging into the system, it is imperative that the system support a federated and distributed mode of user identification and management. This helps manage the complexity of user and role management as well as provide more autonomy to the individual providers. The system should ensure a user is permitted to perform only operations that are relevant to the role of the user.

The system should provide a high level of privacy to the patient by way of ensuring that the information pertaining to the patients shall not be accessed or distributed to parties not authorized by the patient or his provider (in coordination of care scenarios). Patients today give implicit permission to providers to share their information for care provisioning by signing off at front desks before a visit by agreeing to the “Notice of Privacy practices” document. These controls on privacy should be specifiable at the provider (E.g. a provider says no AIDS related information in my practice will be shared) as well as individual patient (E.g. Tom Jones says that he would like to opt out of the electronic sharing of his information) levels.

HIPAA law permits the sharing of clinical data for the purposes of payment, operations and treatment without the prior written consent of the patient. There are various state laws that provide special restrictions on specific class of healthcare data such as genetic test results, mental health information, AIDS/HIV related information, sexual abuse and STD information over and above HIPAA. State law supersede HIPAA in these matters.

Additionally the system should also provide the same level or privacy to the various providing parties of the eco-system.

Any disclosures made through the system should have auditing and logging at the provider level so user actions may be scrutinized for compliance with applicable laws and policies.

The system should be extensible enough to accommodate variations and improvements in technical, infrastructural, legal as well as business standards and practices. Examples of such extensibility include ways to incorporate healthcare related standards such as new versions of HL7, new mechanisms to identify providers (e.g. NPI), new amendments if any that are made to privacy and portability related standards such as HIPAA.

The system should provide an additional level of tracking of operations performed on it through an extensive system of auditing and logging. The system should be able to audit and report on any activity that involves the following

• Transmission, storage, editing or viewing of Protected Health Information (PHI)
• Creation deletion and modification of users and roles
• Changes made to security access permissions for any user
• Changes made to patient or provider level information sharing policies
• Searches that are performed for patients who are enrolled at other providers

It should also be able to present reports on all of the above activities to personnel authorized to access such reports.

The auditing and logging functionality should also be usable for non-repudiation of messages sent between various parties in the system. This improves the level of trust and confidence various parties place on the other parties they interact with.

A multi-vendor environment will encourage competition in the field, leading to better innovations in products as well as lower costs. In light of this, it is imperative that each of the implemented and certified information management system shall interoperate within the scope of the standard, with all the other certified information providers in the nation and possibly beyond.

Most small and medium physician practices have very tight budget constraints. In order to convince such providers to join a HIE, the system should demonstrate a high return on investment right from the first day. For this, the system should have a very low setup and initial deployment costs for hardware as well as software and very low ongoing maintenance costs.

The tangible and intangible savings provided by the HIE system should outweigh the cost of deployment and ongoing operations.

The effectiveness of the HIE and RHIO in bringing all levels of clinical providers into the network depends on the ability of the system to accommodate practices of all sizes big and small. For this, the system should provide a very low barrier for entry to those individual practices which do not have as high level of connectivity or computing resources. For example, a practice that has only a fax machine should be able to participate in the system minimally, exchanging data with other providers. Additionally, the practice should be able to derive additional value out of the HIE with minimal additional investment in the form of internet connectivity and lower cost hardware investments.

A healthcare information system may comprise of multiple processing nodes at the RHIO or HIE level, data collection and dissemination nodes at the practice level and client user interface applications at the end user level.

A mission critical system of the proposed magnitude may potentially involve tens of thousands of client machines, thousands of provider information nodes and hundreds of RHIO and HIE service nodes. Managing all these nodes to ensure health of the system as well as smooth operations is obviously a huge task. The management of all the components of such a system has to be distributable between different governing entities that are responsible for their segment of the system. Additionally, the management tools provided should give authorized administrators very simple and efficient means to monitor manage and administer the systems components. This is critical to eliminating the need to hire, train and retain dedicated IT staff at each practice.

Given the mission critical nature of any HIE/RHIO, it is also required to be always on and available to each of the parties that consume the information contained in the system. The system has to provide timely and accurate responses to request by each of the participants that are connected to it. This means the system has to have multiple levels of redundancy built in the core components.

While the availability of the system may be ensured with adequate hardware and software support, it may be noted that any system that relies on the internet for data transmission will be vulnerable to outages of the internet itself. In order to mitigate this risk, all communications between nodes must be made with necessary precautions to ensure that data will not be lost in the face of intermittent internet connectivity failures.

There are certain scenarios in the medical processes where quick access to key information is a matter of life and death for a patient. For example, accessing information about allergies, medications and problem lists for a patient arriving at the ER is critical to ensuring a reliable treatment process. In such cases, every second the healthcare provider has to wait to retrieve the information is precious. The HIE/RHIO must hence operate within preset metrics that describe the performance and responsiveness. These metrics must be carefully laid down keeping in mind the massive complexity and the amounts of data being transmitted through the HIE/RHIO.

The HIE/RHIO should be capable of scaling up to handle medical information storage and dissemination for the entire nation. This scalability can be achieved by separating the entire system into a set of RHIO’s or HIE’s, each dedicated to maintaining and processing information for a specific region. A network of such RHIOs and HIEs can then be interconnected with each other, providing access to information and services to one another.

The system should be designed in such a way that the individual providers do not have to give up total control of their data into the network. Still, there are certain services that require a centralized deployment model. The chosen system should thus contain elements that are centralized while still enabling a peer to peer model of data sharing between practices.

The system has to be compliant with various security and technical standards such as HIPAA for privacy and security, web service standards for interoperability etc. Additionally, the system has to be adaptable to new standards as they emerge.

The following is a list of some standards with which the system should comply

• HIPAA
• HL7
• XML
• SOAP/Web Services
• CCR

As the center of care gradually gravitate to the patients, they are more empowered by information which they can act on readily and make informed choices. This means the HIE/RHIO should have secure and effective means of allowing patients to interact with it, while maintaining a high level of privacy.

The healthcare platform must be able to support various vertical as well as horizontal industry standards which are relevant to the healthcare area. The following standards are worth considering:

HL7: Standard HL7 messages must be used when communicating with backend systems, as well as with network services such as Labs. This enhances the interoperability of the solution and makes it easier to integrate with other systems.

Secure Web Services and SOAP: All inter-node communications as well as client-server communications must be performed through standard transport and communication layers. SOAP and XML web services are the emerging standards for this type of communication, and is supported on all major platforms today

WS-I (Web Services Interoperability): The system must comply with the WS-I basic profile for web service communications.

WS-Security: for secure communications between nodes in the system

XML: The system must be capable of exchanging information with other parties using XML versions of HL7 documents. This enhances interoperability.

The primary consumers for HIE/RHIO are the physicians and other providers in the medical field. Any efforts in this area must directly or indirectly make business and economic sense to the customers. Additionally, extending the reach of the system to include patients into the loop indirectly improves the performance of the providing clinicians.

The HIE/RHIO must implement one or more of the following use cases in order to provide true return for investment.

• Patient demographics information sharing and updates
• Emergency data propagation and retrieval
• Electronic Referrals
• Patient online check-in to practice
• Electronic Lab Ordering and Results delivery
• Electronic Prescription filling
• Inter-Physician secure messaging

The success of the system revolves around providing equal accessibility to all medical providers big and small. Thus small providers should be able to make minimal upfront investments to get connected in the network and gradually add services and capabilities as their needs change.

The system should provide support for practices and providers who do not implement an EMR or similar medical records management system. Given the slow adoption of EMRs in many practices, it may be unreasonable to require every physician to have an EMR in place. All the functionality of the HIE/RHIO should be accessible from a client interface wherever a separate medical records system is absent. Later, the practice should be able to deploy an EMR system and integrate into the network.

Most small practices across the country would find it very expensive and impractical to employ or contract dedicated IT staff for maintaining and operating a healthcare management system. Hence it is imperative that the system should not require the services of IT staff for ongoing maintenance. The HIE/RHIO infrastructure should be able to support lights-out remote manageability.

The healthcare information network, once operational will gradually cultivate a rich ecosystem of different types of service providers such as Labs, radiology centers, blood banks, prescription services, insurance agencies etc. Hence the system should be built from the ground up with extensibility and interoperability with other parties in mind.

The cost effectiveness and reach of the HIE/RHIO must translate to an inherent ability to leverage it to serve underserved communities in remote locations within the nation. This means the network should be able to extend its reach to communities with limited internet access and investment capabilities. This requirement implies the following additional attributes

• Low cost of entry
• Ease of use
• Simplicity of solution
• Remote deployment (ASP model) and management

Since not all providers may make use of an EMR system, and since none of the EMR systems provide support for the distributed health network model, the chosen solution must also contain a user presentation application. This application should allow clinicians to interact with the network at a higher level and extract information from it.

The client application should have the following attributes

• User friendly
• Basic patient data entry and retrieval operations
• Interfaces for performing search and retrieval of patient information
• View and import patient clinical and demographic information
• Launch pad for collaborative applications
• Dynamically updatable for reduced Total Cost of Ownership
• Expose provider level configuration operations