Common Framework — The interoperability of the Health Information Environment is premised on conformance to a Common Framework, which consists of the essential technical and policy requirements to enable the interoperation of standard interfaces and transactions at the local, regional and national level. (see Question 1 for full description)

Health Information Environment — The NHIN consists of a carefully planned Health Information Environment that meets society's requirements through widespread adoption of a formal set of technical components, standardized methodologies, and explicit policies for use and governance. The Health Information Environment ensures interoperability through open standards, rather than by creation of a new physical network. Existing healthcare IT infrastructure ­ hardware, software, and network connections ­ will be able to interoperate in the Health Information Environment if it conforms or is adapted to use the Common Framework. New deployments of hardware and software will likewise be able to interoperate with legacy systems through conformance to the Common Framework. These standards will allow use of the Internet, private networks, and any new national network infrastructure for the secure transport of essential health care data and transactions. The Health Information Environment will be a "network of networks," where sub-networks of participants grouped together through proximity, as with a Regional Health Information Network (RHIN) or through affinity (as with sites of care operated by entities such as the VA) can use the Health Information Environment's capability to support both data transmission within and among these various sub-networks.

Interoperability — As used in this filing and as presented in the Health Information Environment, interoperability has three distinct components, each of which must be present to enable full participation:

1. At the I/T network access level (here meaning the Internet), Interoperability means the capacity to physically connect a sub-network user to the network for the purpose of exchanging data over its components with other users.
2. At the network authentication level, interoperability consists of the ability of a connected user to demonstrate appropriate permissions to participate in the instant transaction over the network, based on demonstrating appropriate authentication(s) of user and subnet work identity as a privileged party;
3. At the application level, interoperability means the capacity of a connected, authenticated user to access, transmit and/or receive/exchange usable information with other users. The interoperability standard must support the full spectrum from uncoded and unstructured data to highly structured and coded semantics. Therefore, at the application level, there will be a hierarchy of coexisting interoperability information standards to accommodate the varying needs and sophistication of the user information exchange.

Open Standards — The European Interoperability Framework 1.0 identifies these "minimal characteristics that a specification and its attendant documents must have in order to be considered an open standard:

• The standard is adopted and will be maintained by a not-for-profit organization, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
• The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
• The intellectual property ­ i.e. patents possibly present ­ of (parts of) the standard is made irrevocably available on a royalty-free basis.
• There are no constraints on the re-use of the standard."

Patient — The term "patient" as used in this filing is intended to be inclusive of "consumer," "individual," and "person". The patient is any person who has a health record or receives services from the health system.

Record Locator Service (RLS) — The Record Locator Service is the only new piece of infrastructure required by the Health Information Environment. The RLS is subject to privacy and security requirements, and is based on open standards set by the Standards and Policy Entity.

• The RLS holds information authorized by the patient about where authorized information can be found, but not the actual information the records may contain. It thus enables a separation, for reasons of security, privacy, and the preservation of the autonomy of the participating entities, of the function of locating authorized records from the function of transferring them to authorized users.
• Release of information from one entity to another is subject to authorization requirements between those parties; in certain sensitive treatment situations patients or providers may choose not to share information.
• RLSs are operated by multi-stakeholder collaboratives at each sub-network and are built on the current use of Master Patient Indices.
• The Record Locator Service needs to enable a care professional looking for a specific piece of information (PCP visit or ER record) to find it rapidly. An open design question is how and where in the model this capability can best be accomplished.

Reference Implementation Process — The "Reference Implementation" Process is a functional demonstration and testing on a significant scale of the Common Framework that others can easily understand and replicate. The Reference Implementation Process will demonstrate that the Common Framework components, if fully specified, permit secure, standards-based data exchange within a community and among communities. It will further show that the Common Framework permits a variety of high value applications ­ including those directly serving the patient ­ to be rapidly and effectively implemented. The Reference Implementation Process will produce resource materials for use by other sites and sub-networks, and will provide a test-bed for validation of systems to be connected to the exchange.

Sub-Network — The sub-network, an affiliation of users that share health information and/or a technical framework, is the essential building block of the Health Information Environment. Many sub-networks are regionally or geographically based, and some of these cross state or other jurisdictional boundaries. Others, such as national research communities, major federal programs, and large commercial enterprises, are organized around other criteria. Regardless of their organization and geographic span, all sub-networks must conform to the Common Framework in order to interconnect with each other and the relevant regional structures in a consistent and uniform manner. This definition of a sub-network encompasses the notion of a RHIN, and expands it to include other types of organizational structures.

User — Users of the Health Information Environment include but are not limited to patients and individuals designated by them as their representatives, provider organizations of all types, payers, disease and case management organizations. All users must be authorized and authenticated prior to use.