The primary reference implementation work to be done will be in the development of software to bootstrap a HISP. Note: if you edit the lists below, please edit in such a way that numbering does not change, so as to preserve comments that point to specific items.


HISP-in-a-Box is a software implementation model that might be offerred by the HIT Regional Extension Centers, multiple software vendors, or even consultants. The market for HISP-in-a-box is probably divided between the home/small business appliance market and the "data center" appliance market. Certainly, the home appliance market is very large and will be important in consumer health and important for home health agencies. The small business market (<6 providers) is described at: The "data center" market is the same market that CONNECT open source software is designed to support via inexpensive DMZ + data center implementations.

  1. Multi-customer architecture. The HISP-in-a-Box serving multiple organizations needs to be able to receive and send messages for multiple health domain names. This feature may not be required if there is a 1:1 relationship between source and HISP, such as found in small businesses and home appliances.
  2. Multi-platform. There are a choice of framework tools today to build server-side apps not dependent upon a particular operating system. The reference implementation should not choose a language or framework that binds to a particular operating system, though OS-specific optimizations are welcome so long as the same function is supported cross-platform. Exceptions allowed for:
  3. Installable and launchable with minimal end-user training. Every operating system has platform-specific functions for installing and launching server-side functionality. In Windows it may be an InstallShield .zip file; in Ubuntu, "apt-get install nhin-d". Installers should be supported for whichever platforms volunteers are willing to sign up to. There are examples of this in other Open Source applications we should simply re-use. The goal is to enable as many organizations and even individuals to be a HISP. Startup may require using a configuration file to configure essential information such as port numbers and IP addresses to use, but the out-of-the-box experience should avoid requiring HISP administrators to have to edit text files to get the system running.
  4. Minimal licensing requirements. This solution should be something that vendors can pick up, in whole or in part, and incorporate into their applications, so as to save time and effort when adopting the NHIN- Direct specifications. This suggests an Open Source license for the package as a whole that allows proprietary modification and redistribution (such as BSD, Apache, or Eclipse) and ensuring that each component is either compatible with that requirement or separately distributable or swappable (such as Postfix, which is GPL, but which can be distributed separately and/or removed by vendors who wish to redistribute proprietarily). All bespoke work for this project must follow the IPR policy that NHIN Direct has had since inception.

The implementation must serve the following functions:

  1. Send and receive "backbone" messages through a pluggable protocol handler. A "handler" would be specific to a protocol, be it SOAP/UDDI, REST, or SMTP. The protocol handler would likely expose a separate administration user-interface that must be exposable to the HISP administrator. The interface for protocol handling should not require administration by the endpoints.
  2. Maintain a message store for received messages.
  3. Maintain an outgoing message queue for sending messages. Messages that can't be sent immediately are kept in a queue. Healthdomainname admins should be able to view the queue of still-to-be-delivered messages for their healthdomainname; HISP admins should be able to view the complete queue.
  4. Expose access to those messages, allow deletion of those messages and submission of new messages, and other endpoint configuration options through pluggable protocol handlers. Such a protocol might be REST; another may be a combination of POP or IMAP to read messages and SMTP to accept submission of new messages. Note that while administrative options might be exposed through REST, a POP/IMAP/SMTP handler would need some other way to provide configuration options (such as "upload your private key so we can sign & decrypt messages on your behalf" a la nhin-d-agent) so an HTML-based interface for that should be provided.
  5. Provide a web-based interface for HISP administration. Such admin would include management of crypto keys for the HISP and health domains, choice of root certificates/trust circles, and adding/deleting endpoint organizations.
  6. Provide a web-based interface for health domain administrators. Such admin would include uploading keys for a health domain and for specific endpoints, add/remove endpoint addresses (or allow for globs, e.g. "xray-*" for pattern matching), and allow additional root certificates/trust circles/self-signed certs.
  7. Provide a web-based interface for endpoints. While the majority of traffic to endpoints will likely happen over the edge protocols in the long term, bootstrapping and simplicity argues for a web-based interface for end-users to use to access their message store and send new messages. Such an interface should be addressable through a configurable hostname, so that end-users can use a URL like particular to the healthdomain name and not the HISP, easing migration from one HISP to another.
  8. Provide an audit log for inbound and outbound communications that can be persisted for legal purposes: At a minimum, the audit log would need to support the same functions as the receipt acknowledgement from a fax machine.