T1

Part 1: Understanding the NHIN

The Markle Connecting for Health Common Framework describes and defines relationships between three kinds of organizations: individual health care entities, groups of those entities joined together to form a sub-network organization (SNO),¹ and the nationwide health information network (NHIN) as a whole.

Entity: An entity refers to functionally independent participants within the health care system, from single doctor practices up to hospital chains and national organizations, whether public or private.² An entity is any organization, institution, or practice; the only parts of the health care system that are not entities are the patients themselves.

SNO: A SNO is any group of entities (regionally or non-regionally defined) that agree to communicate clinical data with one another using a single Record Locator Service (RLS), using shared policies and technological standards, and operating together under a single SNO-wide set of policies and contractual agreements. A SNO has two sets of interfaces, one internal, which binds its member entities together, and one external, which is where traffic to and from other SNOs and outside entities come from.

NHIN: The NHIN is the sum of all SNOs. It is a network of networks whose participants agree to the Common Framework. The NHIN is not a separately funded entity; it is a framework of cooperation and compliance.³ If the individual SNOs externally facing interfaces work, the NHIN will work. There are no required "top level" services in the NHIN; at the national level, adherence to standards and policies, however defined and affected, are the key elements. All the actual infrastructure of the network is either hosted within the SNOs, or uses the existing internet.

The following diagrams illustrate the relations between entities, the SNO, and the NHIN.

Diagram 1: Inter-communicating entities within a SNO.

A SNO is a collection of clinics, hospitals, labs, and other entities. They can communicate directly with one another, and are all governed and contractually bound by SNO-wide policies. With the exception of Common Framework technical standards and policy requirements, SNOs are free to design the organizational form that best fits their members. For instance, some SNOs will want to offer a number of SNO-hosted technical services such as data validation, while others will want those functions handled by the member entities.

Diagram 2: Two SNOs communicating securely over the Internet.

Every SNO must maintain an interface to other SNOs. This interface is called the Inter-SNO Bridge (ISB.) As the name implies, the ISB is the point of contact between SNOs. While data traffic within a SNO can pass directly between member entities, traffic between entities in different SNOs must pass through an ISB. The ISB exists both to simplify nationwide traffic (so that every entity does not have to know the address of every other entity), and to improve security, by providing a single point of observation for data traffic going to and from the SNO.

Diagram 3: The NHIN is the sum of intercommunicating SNOs.

The NHIN is the sum of all such intercommunicating SNOs, plus those entities required to design, promote and enforce those standards and policies that need to be implemented at a national level. As the nation's health care institutions join together in SNOs, in order to increase the quality of local care while reducing costs associated with incomplete or duplicated data, the NHIN grows as a side effect.

Creation of a SNO

The SNOs are the principal site of implementation of the Common Framework. The size and scope of a SNO is variable; the commonest model for a SNO is likely to be formal incorporation of a group of entities that have already frequent dealings with one another. The principal function of a SNO is to provide a way to share information securely and among authorized users while protecting patient data against accidental or inappropriate disclosure or misuse. The SNO will contractually mandate and ensure compliance with Common Framework standards and policies, and will adopt or enact any additional standards or policies it deems necessary, with the consent of its members.

Levels of SNO Guidelines

There are four conceptual levels at which a given policy or technical standard can be set: national, SNO-wide, per member institution, or no standard.

In keeping with a desire to make the Common Framework as broadly adoptable as possible, we have tried to specify the minimum necessary, assuming that above some floor, different entities will have the flexibility to do more; and we have tried to specify policies and standards at the appropriate level of adoption and enforcement.

For example, we must have a national standard for encryption of data as it passes between SNOs, both to assure that the data is secure and to provide interoperability. Coordination of acceptable identifiers for patients in the absence of a national identifier, however, cannot be handled nationally, because different states regulate e.g., the use of Social Security Numbers (SSNs) differently. This level of standardization must therefore be done by the SNO. Procedures for handling user identity and authentication must be in place, but we cannot require that they be handled at the level of the SNO, because in many cases, members of a SNO will have existing procedures which they will not be able to replace quickly or easily. In these cases, the policy and technical documents set minimum levels of compliance, but do not require SNO-wide standardization.

Lastly, and most importantly, there are those aspects of the health care system that the Common Framework does not propose to standardize. For example, we do not propose standardizing the 'look and feel' or behavior of clinical applications, because such standardization would stifle innovation and is not necessary for different applications to share data (so long as the data itself is in a standard format). The design and implementation of clinical applications is best served by allowing those applications to be tailored to local needs and requirements—a well-funded research hospital will have different application requirements than a safety-net clinic with only web browser access to remote data.

Our view has been that where it is not necessary to standardize, it is necessary not to standardize. Though it is tempting to believe that one can upgrade the entire health care system at once, experience has shown that every required standard raises the cost and difficulty of complying, while lowering the overall rate of adoption. In a system as large and diverse as this one, the essential tasks of improving data quality and creating applications better able to take advantage of that data must be approached incrementally. We believe that the best way to catalyze those improvements are to decisively separate the functions of the network for discovering and transporting that data from the applications that request and consume it.