National Health Information Network (NHIN) Architectural Requirements

We will now proceed to begin to paint a picture of an ideal national architecture. The NHIN has been variously described as a network of networks. The NHIN is the largest network of interconnected RHIOs and HIEs. It is our strong belief that the NHIN should set the technical foundation on which the inventive power of the American innovators should be unleashed. This can be possible only if we take an incremental approach and not try to over design or over specify as standards. We will explain this further as we proceed to describe the architecture.

The NHIN architecture should satisfy certain high level guiding principles in order for it to be successful:

1. Built on core set of internet standards that have wide industry and government support – HTTP/S, Web Services, PKCS (Public Key Cryptographic Services)

2. It should be sufficient yet not over designed. Its power should come from its simplicity so adoption can be easy and ubiquitous. (If we think back at why HTML was so successful, it had a lot to do with its simplicity)

3. It should support a decentralized administration model. Decentralization results in local decision making and implementation. This approach solves the problem closer to the center of action. This will also let a great degree of innovation to flourish at the regional level. The NHIN will project a small number of national use cases that are easy to implement. Only those services that absolutely have to be performed at a central location should be performed there (e.g. a NHIN Certification Authority will be required in order to support the issuance of RHIO certificates to RHIO level certification authorities).

4. The NHIN should operate using existing industry standards as much as possible.

5. The NHIN should enable the participation of existing health information systems by means of application adapters and specify what new applications should provide in order to enable them to “plug” into the NHIN.

6. The NHIN architecture should be scale up to support various types of RHIOs and HIEs (statewide, private extranet, metro wide, interstate, county wide, city wide etc). At the same time it should scale down to support small practices, non-electronic practices and rural and underserved markets.

7. The cost of implementing a NHIN-compliant RHIO should be such that it is affordable to the vast majority of participants (80% or higher). The remaining 20% can be subsidized through some mechanism of government funding or some form of cost shifting (similar to the universal access fee paid by urban telephone consumers to subsidize the rural telephone consumers).

8. The user management function should be decentralized (also known as federated model of user authentication). This way, the local provider organization makes the determination of who should have access to the NHIN functionality. This results in a smaller overhead at the center.

9. The architecture should enable the incremental evolution of RHIOs and HIEs. As new RHIOs and HIEs emerge, they should be able to “plug” into the national network (NHIN).

10. The architecture should provide a minimal set of services that can be implemented by any vendor, RHIO or government agency in order to be compliant and interoperate. The services can themselves be built by different vendors (best of breed approach) or by one vendor (integrated) or someone can choose to use the prototype code as the starting point or the final point. This will foster an open, competitive environment conduce for innovation and lower prices.