NwHIN Specification Preview
The NwHIN is a ‘network of networks’ for exchanging health data. The fabric of the NwHIN is based on web services that provide the framework among NwHIN participants to locate and exchange health information. Examples of NwHIN participants currently include: state level exchanges, IDNs, federal entities, public health entities, and geographically-based health information organizations. In order to qualify as an NwHIN participant, the Health Information Organization (HIO) must receive NwHIN Validation, which includes conformance and compliance testing. NCHICA has been actively participating in and contributing to the NwHIN project since its inception in 2005.
These technical specifications were developed by NCHICA team members and other participants from around the country on the NwHIN Specifications Factory, which is led by the Office of the National Coordinator (ONC). Click here to view the ONC NwHIN web pages. Below an overview of these NwHIN Core Service Interface Specifications:
For the latest updates on the NwHIN Specifications, click here.
Access Consent Policies
Patients’ (aka consumers) primary concern is that their clinical data is only available to authorized clinicians and organizations. Access Consent describes the content and format of policies covering the electronic exchange of health information between HIOs. These policies may be generic or customized by a consumer to grant or deny access to specific types of information by specific types of users. Consent policies can also apply to physicians i.e. they can create a policy that would restrict access to the health information that they create, or restrict access until he/she has discussed the information with the patient. HIOs may need to apply restrictions based on their state’s laws.
When a provider attempts to retrieve existing clinical information through the NwHIN, the initiating HIO can indicate the Policy ID of an Access Consent policy that is associated with a particular patient. In order to query for documents, the responding HIO must retrieve and apply that patient’s Access Consent policy.
Authorization Framework
The Authorization Framework Service Interface Specification involves access to information on HIOs on the NwHIN, and the exchange of that data between the initiator and the responder. The objective is for the responder to enable authorization based on assertions, permissions, and policies. The initiating HIO passes a request with assertions, and the responding HIO consults its local Policy Authority to determine whether it should perform the requested function. One assertion may contain several statements about authentication and authorization.
The Authorization framework is based on SAML (Security Assertion Markup Language). It provides authentication and authorization between security domains. SAML is a standard created by OASIS and is based on HTTP, XML, and SOAP (Simple Object Access Protocol). XML standards are used for signature and encryption, SOAP standards are used for the communications protocol.
GIPSE Profile
GIPSE stands for Geocoded Interoperable Population Summary Exchange. It was created by the CDC to allow the electronic exchange of health condition summary data. GIPSE data will be used by public health agencies for early event detection and monitoring for potential public health events.
GIPSE is still a work-in-progress. It is expected this functionality will evolve over time; HIOs are not expected to support GIPSE at this time. Currently the CDC has focused GIPSE on the exchange of data to support the HHS Biosurveillance Use cases, with a focus on influenzas and pneumonia. Users of this profile will need to consider updated and newly published versions of GIPSE when implementing this profile. GIPSE uses the Health Information Event Messaging (HIEM) Service Specification to support the publish/subscribe model.
Health Information Event Messaging (HIEM) Profile
GIPSE uses HIEM to report public health events to the CDC. HIEM is the publish/subscribe (pub/sub) capability for ongoing feeds of data between HIOs on the NwHIN. It is often referred to as a subscription/notification service. The subscriber can customize the type of events they prefer to receive. HIEM is currently being used to support GIPSE and feed subscriptions for public health surveillance data.
Messaging Platform
The Messaging Platform specification addresses the exchange of health information between organizations in different security domains.
The Messaging Platform describes the common web service protocols that underlie every message transmitted between HIOs on the NwHIN. The NwHIN framework is a web-based service oriented architecture. The messages sent between HIOs are in the form of SOAP messages transmitted over HTTP. Public Key Infrastructure (PKI) is used as the trust fabric of the NHIN. PKI ensures all HIO-to-HIO messages are digitally signed for purposes of authentication and non-repudiation. All HIO to HIO messages are HL7 3.0 RIM-based messages.
The basis for authentication for NHIE participants is X.509 certificates. All HIO certificates will be issued by a common trusted certificate authority yet to be determined. All HIO to HIO messages must be digitally signed for purposes of authentication and non-repudiation.
Patient Discovery
The Patient Discovery Service Interface Specification provides patient arbitration capabilities between HIOs to support querying for documents across HIOs. In order to search for patient data in the absence of a national identifier, this specification uses IHE’s Cross Community Patient Discovery (XCPD). This defines the role of XCPD Initiating Gateway and XCPD Responding Gateway.
For example: John Doe on HIO A does not equal John Doe on HIO B. Prior to exchanging patient specific data, an HIO needs assurance that they are looking at the correct record. The Patient Discovery Service dictates how an HIO will locate and identify patient information that resides on another HIO on the NHIN.
The initiating HIO enters all the demographic data and local identifiers that can be shared about a patient. The responding HIO matches the demographics and identifiers. If a single match is found that is considered highly reliable, it is returned to the initiator, along with its demographic details and identifiers. If no match is found the responder sends an empty response to the initiator, indicating that this patient is not known at this HIO.
If a highly reliable match cannot be identified, an ambiguous response is returned. The service will ask for more information or use a manual process to finish the matching process. Patient Discovery is designed to avoid false positives at all costs.
Query for Documents
The Query for Document Service allows an initiating HIO to request a list of documents about a patient available in the responding HIO. It is dependent on Patient Discovery to provide the patient identifier of the correct patient in the responding HIO. The query permits additional parameters like start/end date and document type to customize which documents are returned.
This interface does not specify whether access consent directives should be enforced during a document query or during document retrieval.
Note that HIOs can store clinical data in whatever format or repository they choose, providing the HIO can respond to queries as described in this interface. The expected use is that these documents transmitted on the NHIN will be formatted as XML data following the HL7 Clinical Document Architecture (CDA) standard.
Retrieve Documents
The Retrieve Documents service allows an initiating HIO to request a specific document, by using a unique document identifier. This is the 3rd step in retrieving data from another HIO, Subject Discovery and Query for Documents are pre-conditions for Retrieve Documents to be executed.
Some HIOs will generate documents “on demand” by aggregating data from multiple sources. They must ensure that the generated document remains available and unaltered after a document has been retrieved once. As noted in the Query for Documents section, internally HIOs can store data in the format/repository of choice, as long as they transmit the data in XML/CDA format.