NHIN Exchange Architecture

For brevity, "Nationwide Health Information Network" is herein abbreviated to "NWHIN."

This page provides an overview of current NWHINExchange architectural principles and their reflection in NWHINExchange architecture and specifications. For a complete overview of NWHINExchange, refer to the NWHINExchange Architecture Overview Document here on the healthit.hhs.gov website.

I. NWHIN Exchange Architectural Principles

1) Local Autonomy – Acknowledges that the decision to release information from one NWHIN Node to another is a local decision, governed by Federal and State regulations and local policies and permissions. Given this principle, NWHIN transactions must include enough information about the originating NWHIN Node (requestor/sender depending on whether it is a push or pull transaction) for the target NWHIN Node to make a decision about whether to participate in the information exchange.
 
  2) Local Accountability - Each NWHIN Node is accountable for the accuracy and truth of the information it provides to assist the decision making process, as embodied by the local autonomy principle.
 
  3) Adherence to standards: The NWHIN has taken the initiative to adopt a series of harmonized standards which have been developed by voluntary consensus standards bodies for exchange of health information among all such entities and networks.
 
  4) Service-Oriented, Layered Architecture: There is a common messaging, security and privacy foundation which supports the NWHIN discovery and information exchange services.
 
  5) Use of Web Services: Web Services provide the basis for transport, discovery and exchange capabilities.
 

• Standard protocol: Functionality is exposed via web services interfaces.
• Web service description: This description is provided via an XML document called a Web Services Definition Language (WSDL) document.
• Finding web services: The discovery capabilities are provided by a listing of web services implemented via the NWHIN Web Services Registry.

II. NWHIN Exchange Architectural Layers

NWHIN Exchange architecture can be illustrated in a traditional layers model. Each layer is defined by the distinct set of specifications, technologies, or mechanisms which define its capabilities. Each NWHIN layer depends upon and extends the capabilities of the layers beneath.
 
  This diagram depicts layers and their components. Each is layer is explained in the text following the diagram.
 
 
 1) Operational Infrastructure includes the runtime systems used to support information exchanges between NWHIN Nodes. Unlike the other layers of the NWHIN Exchange architecture, the these components are implemented and maintained by the NWHIN Program as a foundational utility.
 
 2) Foundation Specifications define the base set of messaging and security standards which must be implemented by each NWHIN Node, as well as the means to convey the meta data needed to inform information exchange decisions. In support of its architectural principles, the NWHIN has defined a non-proprietary, implementation-agnostic foundation.
 
 

• Messaging Platform - adopts Web Services Interoperability (WS-I) Profiles WS-I Basic v 2.0 and WS-I Security v 1.1. Together, these define the NWHIN Exchange's common transport layer specifying a base set of messaging standards and web service protocols which must be implemented by each NWHIN Node and applied to all transactions.
  • WS-I Basic details the use of SOAP 1.2, WSDL 1.1, WS-Addressing 1.0, WS-Policy 1.5 and MTOM 1.0. Together, these provide the basics for information exchange across the NWHIN. Also contained within the WS-I Basic profile is the specification for UDDI v3.0.2 that is used as the implementation of the NWHIN Web Services Registry.
  • WS-I Security defines the security mechanisms required for NWHIN Exchange, including TLS, AES 128, X.509, XML D-Sig, and Attachment Security
• 
  
• Authorization Framework - specifies the mechanism by which responding nodes are provided with the information they require to make an response decision when they have received a request from another NWHIN Node. NWHIN has adopted SAML 2.0 to convey the following information:
• Requestor's method of authentication
  • Requestor's identifying information (e.g. name, role, purpose for use, entity association, and node and patient identifiers).
  • Optional reference to patient's Access Consent Policy
  • Assertion digital signature
• 
  
• 
  

3) Discovery and Information Exchange Service Specifications define the means by which NWHIN nodes discover each other, thier service endpoints, and mutual patients. They also define the availalbe information exchange pattters (e.g Pull, Push, and Pub/Sub). When invoked by an initiating NWHIN Node, these services are directed to specific service end points at one or more responding NWHIN Nodes. Each type of health information exchange transaction employs some combination of these services.

4) Information Exchange Service Profiles** furhter extend or constain Discovery and Information Exchange services in order to define uses of those services to support specific transactions.

• 
  
•