
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.