Collaborative Response to the Office of the National Coordinator for Health Information Technology (ONCHIT) Request for Information (RFI) on National Health Information Network (NHIN)

Technical Overview:

The Health Information Environment will be a "network of networks," where participants, grouped together through proximity, stakeholder trust and patient care needs, will drive the formation and evolution of sub-networks. As with a Regional Health Information Network (RHIN) or through affinity (as with sites of care operated by organizations such as the VA), the Health Information Environment will support data transmission both within and among these various sub-networks. 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 network infrastructure for the secure transport of essential health care information and transactions.

The technical attributes and common requirements of the Health Information Environment include:

• A Connected Environment based on Sub-Networks Built on the Internet. It permits participating sub-networks and their authorized users to access only appropriate information on demand in a private and secure manner. Subnetworks may be determined geographically or be based on other relationships
• The Health Information Environment is predicated on a decentralized and federated model that protects the privacy and security of information and allows accurate and timely access to information.
• The Health Information Environment is premised on a “Common Framework” consisting of the technical and policy standards essential to ensure privacy, security and interoperability, serve the patients whose data it shares, and connect systems of varying technical sophistication.
• The detailed design principles of the Health Information Environment are:
1. Decentralized. Data stays where captured: The U.S. healthcare system is fragmented. Many types of institutions are part of the current healthcare network, from giant hospital systems to individual practices, with all manner of specialists, clinics, and agencies in between. The decentralized approach reflects the legal and market realities of healthcare. The Health Information Environment facilitates the transfer of selected information from one end-point system to another (not necessarily the source system), as is required for providing care and supporting informed patient participation in care. The decentralized approach obviates the need for storing identifiable data in a central database, but builds on existing aggregates of data where available or necessary. The infrastructure facilitates information access by authorized end-point systems, or proxies for them, to improve the delivery of patient care and to further other health-related goals. Even though the infrastructure is decentralized, it supports and facilitates authorized aggregation for public health, quality management and other functions.
2. Federated. To maintain the local autonomy of decentralization, a common set of policies, procedures, and standards to facilitate reliable, efficient sharing of health information among authorized users is required. These standards or practices specify when patient information can be shared, which information can be shared, and how the information can be used. That is, the participating members of the health network must belong to and comply with agreements of a federation. Federation, in this view, is a response to the organizational difficulties presented by the fact of decentralization. Formal federation with clear agreements allows participants to access information that has been authorized to share.
3. Private and Secure. All of the activities of the Health Information Environment, including the delivery of care and the conduct of research and public health reporting, must be conducted in an environment of trust, consistent with appropriate requirements for patient privacy, security, confidentiality, integrity, audit and informed consent. All those that generate health information for patients are its stewards. Patients control access, in partnership with their providers.
4. Accurate. Accuracy in identifying both a patient and his or her records with little tolerance for error is an essential element of the Health Information Environment design. The Health Information Environment must also create feedback mechanisms to help organizations to fix or “clean” their data in the event that errors are discovered.
5. Reliable. Assurance of a uniform minimum degree of system service quality (e.g., reliability, dependability, etc.) in addition to backup mechanisms, so that stakeholders can count on the availability of the overall system.
6. Fast. Near real-time information access is crucial, not only for routine clinician and patient needs, but also for particularly time-sensitive specialties such as emergency medicine and monitoring of disease outbreak, bioterrorism, or contamination of the food supply.
7. Interoperable and built on a 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. The technical standards address secure transport over the Internet and other networks, and provide the essential components required for the infrastructure including secure connectivity, reliable authentication and a suite of defined interchange formats for health care data. The policy standards address the privacy, use and access policies for the exchange of health information. The Common Framework also provides a uniform methodology for the identification of users. The modular character of the Common Framework permits rapid attainment of an interoperable information environment using essential requirements but also scales to a more complete structured data interchange for enhanced performance. The suite of interoperability standards will be enhanced over time. The Common Framework is the basis of all subsequent use cases that require specific, uniform interoperable standards to support information exchange. Use cases and accompanying information standards will be specified for each of the myriad of health information exchange requirements and will be supported by detailed implementation guides. The participants in subnetworks will determine which profiles are appropriate to address the requirements established by their stakeholders. The Common Framework, and mechanisms to enforce compliance with it, ensures the creation, interoperability, scalability, efficiency and ongoing evolution of this environment. The Common Framework should be required across all health communities, including the clinical research community, public health, etc. The Common Framework is further described in subsequent sections.
8. Designed to Respect and Serve Patients (in addition to the Health System and the Public). The Health Information Environment is premised on a model of patient authorization and control. Patients must be able to: choose whether or not to participate in sharing personally identifiable information; exercise their rights under HIPAA; control who has access to their records (whether in whole or in part); see who has accessed their information; review, contribute to and amend their records (without unreasonable fees); receive paper or electronic copies of their information; and reliably and securely share all or portions of their records among institutions. Once patient consent has been granted for a certain type of information access, however, information should be able to be accessed freely in a trusted environment.
9. Flexible. The Health Information Environment is flexible in several ways. First, it is heterogeneous with regard to the types of technology and function of the sub-networks and other entities that use it, providing that all of them adhere to the Common Framework. This enables users of varying levels of technical and functional sophistication to use it for a variety of processes. Second, it is flexible in that it facilitates communication among end-point systems at varying levels of sophistication in the structured and coded representation of data and supports the evolution of systems in this regard. For example, while some might use the Health Information Environment to locate records and request them by telephone, others may draw on it to support the full electronic exchange of highly structured data for sophisticated data analysis and decision support. This is necessary because health information will continue to be a mix of unstructured and structured and coded data. The Common Framework provides standards and procedures that allow two systems that support highly coded data to exchange it without loss of data, a system that supports less or little coding to receive information from comparable and from highly structured systems, and a system that supports a high level of coding to receive, file, and make use of lightly coded data when this comes from another system. Lastly, the Health Information Environment is flexible also in that it is able to evolve over time to address the changing needs of users and to increase in scale as the numbers of users and their transactions grow; it supports a reasonable level of variation and innovation in response to local needs.

What the Health Information Environment is not

• A “Big Bang” Undertaking. Although the need for a Health Information Environment would warrant a "moon-shot" type approach to its building, political and practical realities suggest that an incremental approach would gain more support. Given the complexity, diversity and distributed nature of the existing U.S. health system, an incremental approach that builds on and integrates existing networks is more likely to succeed. Therefore, this is not a "big-bang" approach. Furthermore, the standards, validation mechanisms, and governance structures cannot spring into existence at once. The Health Information Environment should be coordinated and built on a plan that recognizes the need for a learning curve. The lessons learned from developing harbinger regional or other sub-networks can prove and improve approaches, leading to accelerated replication and success based on early experience.
• A Central Data Repository. The Health Information Environment is not based upon a national central repository of patient information. Instead, it is a pathway that facilitates, with appropriate authorization, private and secure information identification and access among regional and other sub-networks. Health information resides with the healthcare providers that generate it and/or with patients themselves.
• A Significant Financial or Technical Barrier to Connectivity. The Health Information Environment minimizes any additional financial or technical barriers (other than the requirement to comply with the Common Framework) to information sharing for patient care.
>
• Proprietary. The Health Information Environment is not a proprietary network owned and operated by particular stakeholder groups.
• The Applications that Rely on It. Healthcare applications or end-point systems (e.g., EHRs) rely on the Health Information Environment and are important extensions of it, but not strictly part of it. Furthermore, the Health Information Environment is not itself an application.

Significant Barriers

• Health care payment and investment policies that do not stimulate improved information access or healthcare quality.
• Misalignment of financial burden and ROI among providers, payers, and patients.
• Inadequate capital for initial investment in infrastructure, systems, and implementation of standards.
• Financial instability of some technology vendors, particularly EHR vendors.
• Lack of a robust market for innovation.

Technical

• Lack of technical specifications, standards and essential requirements for interoperability that can be validated and will work in all of the sophisticated and unsophisticated environments in healthcare.
• Lack of experience raising standards for interoperability to a regional or national level.
• Need for continued progress in developing common nomenclature and vocabulary definitions.
• Lack of a standard mechanism for patient identification.
• Lack of user-friendly interface designs and implementation support for clinical and other applications.

Environmental

• Complexity, vastness, fragmentation, and sheer volume of health transactions required by the health system.
• Overlap, competition and fragmentation of existing standards development efforts.
• Healthcare payment policies and regulations that call for the inconsistent reporting of data or manipulation of data or codes.
• Inconsistency of laws for information sharing among states—some that may require further policy clarification or action to resolve.

Educational/Attitudinal

• General lack of public information and understanding about the potential benefits of access to electronic health information for personal health decisions and health care services.
• Public and professional concerns about privacy and security of information.
• Professionals’ reluctance to use electronic health records, whether because of potential disruption of workflow, lack of technical and implementation support or other concerns.
• Provider concerns related to liability resulting from the potential availability of additional data for which they may be responsible.
• Lack of research on and understanding of workforce development as it concerns health IT. Areas needing attention include: just-in-time training to help providers and support staff to adapt their work processes; initial and continuing education of health information specialists (e.g., IT specialists, health information management professionals, applied information management professionals); and research on evolving information management practice domains.

Significant Enablers (While the opposite of every “barrier” could be listed as a potential “enabler,” we have chosen to identify only enablers that we believe already exist, to varying degrees.)

• Increased financial support (from public and/or private sources) for technology adoption, implementation, and training tied to requirements for information standards, patient identification, and interoperability.
• Growing interest on the part of new entrants to the market for IT tools and services as a result of the financial scale of the market.
• Pay for performance, including incentives for information sharing for improved patient care.
• Underserved populations may require financial and other support to ensure that they have access to and can benefit from the Health Information Environment.

Technical

• Developments in information technology sharing tools and process management techniques that enable new decentralized architecture models.
• Growing availability of broad-band access or other connectivity options.
• Digitization of medical technology and research, increasing demand for interoperability of data.

Environmental

• Growing political support in the Administration and Congress (including the creation of ONCHIT).
• Demand (patient, political and financial) for high quality, affordable health care for all.
• The lessons learned from developing harbinger regional or other sub-networks can prove and improve approaches, leading to accelerated replication and success based on early experience. Large Integrated Delivery Networks, smaller independent providers, and vendor groups have participated in IHE’s testing processes and provided opportunities for learning. Additional lessons learned in the United Kingdom, Canada, Australia, and other international venues to revamp infrastructure and promote interoperability should not be overlooked.
• Agreement on conformance validation mechanisms for interoperability.
• Agreement on mechanisms for protecting the privacy, security and integrity of health information and the initial Federal floor established by the HIPAA Privacy Rule.
• Industry consensus on basic administrative, physical and technical framework for protecting health information and security.
• Industry consensus on the development and adoption of information standards including those that: allow clinical data captured at the point of care; are compatible, easily coordinated, and satisfy diverse user requirements to share and aggregate data; enable systems with varying levels of structured and unstructured data to communicate.
• Proliferation of regional, state, and local initiatives eager to move rapidly and conform to emerging national protocols and policies. (Note that it is essential to define a Common Framework soon so disparate initiatives do not develop in incompatible ways.)
• Legal safe harbors with restrictions.

Educational/Attitudinal

• Support for increased patient education to help people understand the value of the network, its privacy and security protections, how to participate in it, and the rights and benefits afforded to them.
• Professional and industry programs for technology adoption, training and support.
• Growing patient expectations, interest, and awareness.
• Payer and employer commitment to IT adoption and health system transformation.
• HIPAA rules, which have created an emphasis on privacy issues.

Question 2. What type of model could be needed to have a NHIN that: allows widely available access to information, enables interoperability, protects personal data, allows vendors and other technology partners to be able to use the NHIN in the pursuit of their business objectives? Please include considerations such as roles of various private-and public-sector entities in your response.

The model for the Health Information Environment that will fulfill these requirements must:

• Create a market for health IT rather than forestalling one.
• Enhance existing and new sub-networks by interconnecting without overburdening them.
• Minimize “barriers to entry” in its development.
• Be built upon existing infrastructure (no “rip and replace” and “no new wires”) including:
• Internet standards, particularly http, SOAP, and SSL
• The Internet itself as a means of transport and interconnection
• Current IT platforms (e.g., labs, rx, EMR)
• Current master patient index (MPI) systems and technologies
• Current patient-doctor and patient-organization (e.g. institution or plan) relationships for authentication
• Current standards identified by the Federal Consolidated Health Informatics Initiative (CHI) including, but not limited to ANSI, ASC X12, NCPDP and HL7 industry standards.

The Health Information Environment will grow incrementally with the creation and expansion of sub-networks:

• Stakeholder trust and patient care needs will drive the formation and evolution of sub-networks.
• The Health Information Environment will be developed through a combination of “top-down” (i.e., nationally-defined) policies and standards, and “bottom-up” (i.e., community and market-driven) initiatives.
• Development of the Health Information Environment MUST be facilitated and supported by:
• Ensuring that all sub-networks conform to the Common Framework, in order to interconnect with each other in a consistent and uniform manner.
• Early demonstration of the ability to effectively exchange usable patient information within and among sub-networks.
• Early establishment of a Reference Implementation Process on a significant scale to reliably and quickly develop the technical and policy requirements for the Common Framework. The first formal version of the Common Framework will be completed after learning from this process and will serve as a basis for others.
• The accuracy, responsiveness, security, and scalability of the system as demonstrated by the Reference Implementation Process, which will foster broader implementation by vendors, and accelerate deployment in sub-networks. The same cycle will need to be repeated as the Common Framework is extended.
• The Standards and Policy Entity (SPE), which, when it is established, will take over primary responsibility for the development of the Reference Implementation Process and policies of the Common Framework.
• Subsequent reference implementations that define the profiles or suites of standards for a complete set of use cases that will also be a primary responsibility of the Standards and Policy Entity (SPE).

On the specific issue of privacy and data protection and the linking of patient records:

• The Health Information Environment requires uniform adherence to a set of policies that are based upon local or sub-network trust relationships, protect privacy and security (at or above applicable federal and state legislation and regulation), minimize the risk of user data misuse, and provide for accountability, transparency and oversight.
• The Health Information Environment is premised on a model of patient authorization and control. Patients must be able to: choose whether or not to participate in information sharing; exercise their rights under HIPAA; control who has access to their records (whether in whole or in part); see who has accessed their information; review, contribute to and amend their records (without unreasonable fees); receive paper or electronic copies of their information; and reliably and securely share all or portions of their records among institutions.
• The Health Information Environment does not require the use of a mandated national unique health identifier.
• However, standardized methodologies are required to identify patients and these methodologies must accommodate any broadly accepted identifier that may emerge to be used as additional sources of likelihood of match. No system will ever rely on a single identifier, as some secondary set of information will be needed to resolve ambiguous matches.
• Any proposed solution for accurately linking patient records must:
• Support the accurate, timely, private and secure handling and transmission of patient records.
• Increase the quality of care, the economic sustainability of the healthcare system, and the privacy of patient data.
• Create value for many different kinds of participants, including (but not limited to) individual healthcare professionals and patients.
• The Health Information Environment is a network of networks, linked only by registries through which information about how to find the sources of authorized records can be found, not any of the actual content of the health records. The registry system knows only where authorized records are, not what is in them.
• To achieve these capabilities, the Health Information Environment requires the addition of one new piece of infrastructure at the sub-network level based on an architecture that separates the function of locating authorized records from the function of transferring them to authorized users. This piece of infrastructure is the Record Locator Service (RLS), described later in this response, and is operated by a multi-stakeholder collaborative at the regional or non-geographic sub-network level and built on the current enterprise use of Master Patient Indices. The Record Locator Service itself is subject to privacy and security requirements, and is based on open standards set by the Standards and Policy Entity.
• The system supports
  1. Linking of records via a registry of information about where records are located and sharing among users participating in the system, but it also allows
  2. Linking without sharing, or sharing pursuant only to higher authorization, as well as
  3. The ability to choose not to link information in certain sensitive treatment situations determined by users.
  By leaving these decisions at the edges (e.g., with patients and the professionals that support them), the architecture supports a range of approaches. It also allows higher levels of approval to be set locally for sharing some records. This obviates the need to have “one size fits all” policies as would be necessary for centrally controlled approaches. 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.

On the specific issue of disclosure and accountability:

• Before a provider initiates a transfer of personal health information, affected patients should fully understand the policies in place and the possible uses of that information. The Health Information Environment is premised on a model of patient authorization and control. Patients must be able to: choose whether or not to participate in sharing personally identifiable information; exercise their rights under HIPAA; control who has access to their records (whether in whole or in part); see who has accessed their information; review, contribute to and amend their records (without unreasonable fees); receive paper or electronic copies of their information; and reliably and securely share all or portions of their records among institutions. Once patient consent has been granted for a certain type of information access, however, information should be able to be accessed freely in a trusted environment.
• Information elements central to network functioning, such as identifiers, authorizations and permissions, access histories, and location entries, must be presented in easily understood terms and formats to patients and other authorized users for their review and possible correction.
• Patients must be able to gain access to any of their information available across the national network, consistent with HIPAA.

• The Common Framework does not dictate, recommend or imply specific tools, platforms, products, or vendors. Access to the Record Locator Service and other functions of the environment requires conformance to the Common Framework. Without this, every entity that has to interact with the network would be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
• While the Health Information Environment is built using the existing Internet, it has to anticipate and take advantage of migration to next generation technology, which will include better and different approaches to ensuring privacy and security and performing other functions.
• The Health Information Environment must have a wide variety of capabilities as articulated in question 1 (e.g. consumer, provider, research, and public health).
• The Health Information Environment is flexible in several ways. First, it is heterogeneous with regard to the types of technology and function of the subnetworks and other entities that use it, providing that all of them adhere to the Common Framework. This enables users of varying levels of technical and functional sophistication to use it for a variety of processes. Second it is flexible in that it facilitates communication among end-point systems at varying levels of sophistication in the structured and coded representation of data and supports the evolution of systems in this regard. For example, while some might use the Health Information Environment to locate records and request them by telephone, others may draw on it to support the full electronic exchange of highly structured data for sophisticated data analysis and decision support. This is necessary because health information will continue to be a mix of unstructured and structured and coded data. The Common Framework provides standards and procedures that allow two systems that support highly coded data to exchange it without loss of data, a system that supports less or little coding to receive information from comparable and from highly structured systems, and a system that supports a high level of coding to receive, file, and make use of lightly coded data when this comes from another system. Lastly, the Health Information Environment is flexible also in that it is able to evolve over time to address the changing needs of users and to increase in scale as the numbers of users and their transactions grow; it supports a reasonable level of variation and innovation in response to local needs.

• 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.
• Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
• The technical standards address secure transport over the Internet and other networks, and provide the essential required components for the infrastructure including secure connectivity, reliable authentication and a suite of defined interchange formats for health care data.
• The policy standards address the privacy, security and use and access policies for the exchange of health information.
• The Common Framework also provides a uniform methodology for the identification of users.
• The modular character of the Common Framework permits rapid attainment of an interoperable information environment using essential requirements but also scales to a more complete structured data interchange for enhanced performance. The suite of interoperability standards will be enhanced over time.
• The Common Framework is the basis of all subsequent use cases that require specific, uniform interoperable standards to support information exchange. Use cases and accompanying information standards will be specified for each of the myriad of health information exchange requirements and will be supported by detailed implementation guides.
• The participants in sub-networks will determine which profiles are appropriate to address the requirements established by their stakeholders.
• The Common Framework, and mechanisms to enforce compliance with it, ensures the creation, interoperability, scalability, efficiency and ongoing evolution of this environment.
• This work will necessarily involve choices that eliminate some of the variability in the standards while attaining interoperability.
• The Common Framework enables a set of open, non-proprietary interfaces and information transfer protocols to be developed to achieve interoperability. This also permits less standardized records to be accessed reliably and rapidly; it facilitates the best possible interoperability among end-points systems of differing levels of sophistication.
• The Common Framework relies upon standards for data content and transmission developed by nationally accredited organizations using an open and consensus-based process. It builds upon existing standards development activity and HIPAA.
• The Common Framework should be required across all health communities, including the clinical research community, public health, etc.

• The Common Framework, and mechanisms to enforce compliance with it or other applicable standards and policies will be an essential condition of the development of the Health Information Environment. The Common Framework ensures the creation, interoperability, scalability, efficiency and ongoing evolution of this environment. Mechanisms to test and validate compliance may be necessary in several domains, including the “highest” or network environment level, the sub-network level, and the level of end point applications (e.g., EHRs). Validation methodologies should be appropriate to the information exchange, requiring only the elements and protocols essential to participation in the Health Information Environment, in a way that encourages innovation and new entrants to the market.
• An external mechanism for validating compliance with the standards of the Common Framework is required for the early phases, but the network may eventually become entirely self-validating. There is uncertainty about how long the outside compliance validation mechanism may be necessary—until the point at which there is a significant level of stability in the Health Information Environment. From the beginning, self-assessment should be built into the compliance validation mechanism because it helps to assure that programs are on track on a continuous basis, rather than waiting for an outside party to identify significant problems.
• Interface and transaction interoperability standards should allow for the appropriate and authorized integration of financial transaction information with related clinical transactional data.
• The Health Information Environment is inclusive of participants of varying levels of technical and functional sophistication. Its standards, rules and vocabularies can accommodate a wide variety of participants at any one time and can also be revised over time as user requirements evolve.

On the specific issue of market incentives and business objectives

• Healthcare suffers from a fragmented and stalled market for IT—both for connectivity and IT adoption generally.
• There is no “network effect” today in healthcare IT.
• The promulgation of a Common Framework will immediately accelerate the value of adopting IT by creating confidence in the ability of IT systems to reliably enable connectivity. Agreement on conformance validation mechanisms for interoperability will enhance this effect.
• This approach should catalyze a market by creating a level playing field for market competition. Nevertheless, widespread adoption of interoperable clinical IT will still depend on investment in the key components of the Health Information Environment and the use of incentives that recognize appropriate information use in clinical care.
• Incentives can include a wide variety of options from fundamental payment reform to eligibility for Federal assistance, eligibility to participate in federal demonstration projects, private-sector pay for performance incentives that require interoperability specified by the Common Framework, and eligibility to receive private IT adoption assistance.
• Incentives that reward the improved decision-making and quality of care enabled by the Health Information Environment will be more effective at driving participation than incentives tied specifically to IT adoption or network participation.

Question 3. What aspects of a NHIN could be national in scope vs. local or regional? Please describe the roles of entities at those levels.

• The Health Information Environment will take shape incrementally, over time. Its development will include both “top-down” (i.e., nationally-defined) policies and standards, and “bottom-up” (i.e., community and market-driven) initiatives.
• Both local and national strategies are needed. Most healthcare is local, and a great deal of information access occurs in a patient’s own community. At the same time, many patients receive care, coverage, and benefits across multiple regions; also, the US population is highly mobile, whether moving across state lines from home to work or from winter to summer homes. Many multi-institution networks, that effectively comprise local health information infrastructures, already exist and must be accommodated.
• In general our proposed model for the Health Information Environment is decentralized and regionally driven. It is desirable to leave to the local systems those things best handled locally, while specifying at a national level those things required as universal in order to allow for interoperability among regional systems. The Common Framework, comprised of the essential security and interoperability standards required to assure secure Internet transmission or patient matching methods, must be national, so that all participating institutions can connect to one another securely and without unworkable variation.

The various regional and national roles and entities for the Health Information Environment are:

• Each region or sub-network needs an entity (Sub-network Organization) to oversee its health information environment. Regional sub-networks have a public interest responsibility to address the needs of the entire population and all health information providers. Some sub-networks will be geographically based and others will be functional or organizational, crossing geographical boundaries. Some of these enterprise or private sub-networks (e.g., a large health system or research network) may not be subject to the same public interest governance and policy obligations. The responsibilities of the Sub-Network Organizations include:
1. Establishing a multi-stakeholder governance structure that includes the representation of patients and consumers and safety net providers. The governance structure should be formalized and address the corporate and tax status of the Sub-Network Organization, its business plan and budget, intellectual property ownership and management, the entity’s statement of purpose and objectives, its decision making model, and its long-term strategic plan. Various types of governance model are acceptable.
2. Defining and meeting the particular information access needs of the region or sub-network while addressing the needs of patient populations that cross multiple communities nationwide or are contiguous but cross state lines.
3. Organizing the creation of “Articles of Federation” and other user agreements. A common set of multi-lateral policies, procedures, and standards to facilitate reliable, efficient sharing of health data among authorized users is required. The participating members of the health network must belong to and comply with agreements of a federation. Formal federation with clear agreements allows participants to access information that they have been authorized to share.
4. Supervising uniform adoption of information sharing policies or Articles of Federation by participating entities and mechanisms for their enforcement (e.g. sanctions).
5. Developing policies to address the need for retention and persistence of data.
6. Addressing conflicts among relevant stakeholders in a timely way.
7. Building, maintaining and managing the regional Record Locator Services and other sub-network systems and services.
8. Assuring that sub-network systems and the end-point systems of their members (including the Record Locator Service) adhere to the Common Framework.
9. Providing support to participants in the federation.
10. Establishing the financial sustainability models for the entity— responsibilities include:
1. Working with community payers, purchasers and providers to discuss participation, incentives and appropriate funding models.
2. Monitoring relevant stakeholder participation regarding conformance with the Common Framework and adoption incentives.
11. Ensuring that all of the information capabilities that define the Health Information Environment (including public health reporting and surveillance, research and improving health care quality) can be met over time.
• In regions where there is low potential for an organizing function, (e.g., rural and underserved), other models of non-geographic sub-networks and Sub-Network Organizations should be established to support these necessary subnetworks. For example, there may be cases, especially in rural areas, where specialized clinical data repositories, or proxies, are shared by the providers in the community. Rural networks that may be meeting the needs of relatively closed provider networks may be best served by shared clinical data repositories that allow acceptable access speeds even when broadband Internet access is limited or less efficient. Any model must include the possibility for such clinical data repositories or proxies to exist as long as they comply with the Common Framework for interacting with other sub-networks as appropriate for patient care or other authorized use. Alternatively, some Sub-Network Organizations can explore potential partnerships with the appropriate State Health Departments, Medial Societies, NGOs, etc.

National

• A Standards and Policy Entity (SPE) to identify and recommend standards and policies for the “Common Framework”-a set of essential technical and policy requirements that enable the interoperation of standard interfaces and transactions at the local, regional and national level (more fully described in the next question).
• Privacy guidelines and policy clarification re: HIPAA, anti-kickback, potentially conflicting state laws and anti-trust laws.
• Performance and accountability metrics
• Experimentation with and creation of financial incentives that require the Common Framework
• Special attention, funding and mechanisms of support for rural and underserved communities
• Enforcement policies for misuse of data
• Coordinated efforts to ensure public understanding of the benefits of health information exchange and patients’ rights in the information exchange environment.

Organizational and Business Framework

Question 4. What type of framework could be needed to develop, set policies and standards for, operate, and adopt a NHIN? Describe the kinds of entities and stakeholders that could compose the framework and address the following components:

1. How could a NHIN be developed? What could be key considerations in constructing a NHIN? What could be a feasible model for accomplishing its construction?
2. How could policies and standards be set for the development, use and operation of a NHIN?
3. How could the adoption and use of the NHIN be accelerated for the mainstream delivery of care?
4. How could the NHIN be operated? What are key considerations in operating a NHIN?

• An over-arching principle in the development and operation of the Health Information Environment is the importance of serving the public interest: it must above all meet the needs of patients by enabling the provision of high quality care at reasonable costs.
• Consumer and patient advocates, amongst all other stakeholders, must be represented on an equal footing in the governance and advisory structure of all regional and national Health Information Environment authorities, including standard-selection and operational entities. Beyond this requirement, various governance models should be explored to balance stakeholder input while not becoming unduly burdensome.
• The Health Information Environment, like the Internet that functions as its core, will not be operated by a central entity. However, like the Internet, which has centralized functions such as domain name assignment, the Health Information Environment will require the centralization of some functions, such as those to be carried out by the Standards and Policy Entity described below.

The Five Critical Key Components of the Health Information Environment are:

1. The establishment of the Standards and Policy Entity (SPE):
   1. The SPE is a public-private collaborative entity that identifies and specifies the detailed implementation rules, including business rules, for the standards and policies that make up the Common Framework. It identifies and recommends the technical standards and information policies essential for establishing privacy, security and interoperability. The SPE is responsible for the identification, specification, interpretation, and dissemination of these standards and policies.
   2. Given the unusually sensitive nature of health information and the complexity of the technical standards and policies needed to guide its use, it is imperative that a single entity – the SPE – be responsible for decisions related to both domains so that they can be closely integrated. While the SPE must be the authority regarding matters in both domains, it may delegate pieces of its work requiring particular expertise to other entities. The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE.
   3. Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
   4. The SPE must not be disproportionately dependent on any of its stakeholders for its funding and must operate independently.
   5. The SPE requires public and private support.
   6. The SPE’s governance and administration must be transparent, accountable, and reflect the participation of all stakeholders, including representatives of the general public who are able to participate on an equal footing. The SPE administration includes a mechanism or formal process that reflects the participation of sub-networks and regional organizations.
   7. The SPE must protect the public good and ensure that consideration be given to enforcement functions.
   8. The SPE must be established and funded as soon as possible in order to continue the work of defining the Common Framework under which all the sub-networks will operate. Once the initial set of policies and standards are in place, and with proper incentives, the Health Information Environment will begin to grow and evolve organically and continually.
   9. The SPE must strive for maximum cost-effectiveness by building on existing standards and policy work (no “rip and replace”), establishing legitimate yet efficient processes and minimizing the negative economic impact of any new requirements it defines. As a general principle, the SPE should seek existing solutions and minimal modifications, creating new solutions only as a last resort. Even so, some change will be required to ensure interoperability across the boundaries of existing standards. The extent of such change must be determined using a defined process. To do so effectively requires close and continuous interaction with standards development organizations (SDOs) and other potential sources of relevant models for its own work.
   10. The requirements for interoperability will be specified in a suite of profiles or use cases defined and detailed by the SPE and premised on the Common Framework. The use cases will be specified via the selection of candidate suites or profiles of standards, for which detailed implementation and technical guides will be made available. The SPE must balance what is practical to implement with the needs of the nation.
   11. The SPE may be an existing organization or a new organization modeled after other quasi-governmental or public-private organizations. Immediate, near-term efforts need to include an analysis of both the public and private sectors for viable models. These efforts should be completed in no more than one year. The analysis of organizational models could be conducted by the Institute of Medicine (IOM), an agency of the NRC such as the CSTB, a new specially appointed Commission/Task Force, or other existing entity with the appropriate stature and credibility.
   12. The SPE must vigilantly guard against an accretion of duty or scope over time: its mission must always be to define and maintain the minimum framework necessary for the successful operation of the Health Information Environment.
2. The creation of multi-stakeholder, collaborative, public interest Sub-Network Organizations at the regional or the non-geographic “sub-network level” that facilitate the development, implementation, and application of secure health information access by establishing and overseeing the sub-networks’ governance and operation (including the Record Locator Service).
3. Financial and non-financial incentives to increase HIT adoption by clinicians and other information suppliers and users and to encourage their connectivity consistent with the Common Framework. These incentives may include loans, grant funding and private and public investment through reimbursement changes. Three tiers of funding and incentives need to be in place to build the Health Information Environment:
1. Providing support for ongoing investment in the Common Framework and the standards and policies created and maintained by the SPE
2. Providing sufficient funding to seed the creation of self-sustaining regional initiatives consistent with the Common Framework
3. Accelerating the adoption of electronic health record systems that adhere to the Common Framework, and that promote high quality healthcare based on greater access to health information.
4. A mechanism for validating compliance with the SPE Common Framework and standards. Early in the evolution, a separate private sector mechanism that may or may not be distinct from the SPE, is needed for validating compliance with the SPE Common Framework and standards and policies. Ultimately the network effect may create a mechanism for self-enforcing compliance. The method for validation must encourage, not deter, new entrants to the health IT market for tools and services to encourage competition and innovative business models.
5. Special attention must be given to underserved communities to ensure that they receive additional support and that they are mandatory, early participants in regional initiatives and sub-networks. In regions where there is low potential for an organizing function, (e.g., rural and underserved), other models of non-geographic sub-networks and Sub-Network Organizations should be established to support these necessary subnetworks. State Health Departments, medical societies, or other non-government organizations may be able to assist in these communities. As with other health policy issues that affect underserved populations, government funding may be necessary to support this goal. See further elaboration earlier in this draft.

Question 5. What kind of financial model could be required to build a NHIN? Please describe potential sources of initial funding, relative levels of contribution among sources and the implications of various funding models.

• We have prepared a single response to questions 5 and 6 because there is great overlap in the financial model to build the Health Information Environment and to operate and sustain it. There are, indeed, requirements in the early years that must precede other activities that could be considered a “build” period and these will be identified below. However, many of these same activities must persist throughout the lifetime of the Health Information Environment. Furthermore, “building” the Health Information Environment will continue indefinitely and the distinction between “building” and “operating and sustaining” the Health Information Environment will blur.

The Health Information Environment is premised on creation of value:

• The Health Information Environment development approach must create value for all of the stakeholders it connects, including (but not limited to) payers, providers, and consumers. It must build and sustain a robust marketplace for investment and continuous development of the infrastructure.
• The Health Information Environment creates value, and does not incur net, long-term costs for the federal government or other stakeholders.
• The Health Information Environment will create value by returning greater financial savings to U.S. society through use of HIT than the costs incurred through adoption of EHRs, the sub-networks of which they are part, and the support of the environment in which they operate. (See “Accelerating US EHR Adoption: How to Get There From Here, Recommendations Based on the 2004 ACMI Retreat” by Blackford Middleton, W. Ed Hammond, Patricia F. Brennan, and Gregory F. Cooper,, J Am Med Inform Assoc. 2005; 12: 1319.)
• Full systematic interoperability has been estimated to save $78 billion per year in the United States compared with current manual methods of data recording, re-recording and transport. (See "The Value of Health Care Information Exchange and Interoperability" by Jan Walker, Eric Pan, Doug Johnston, Julia-Adler Milstein, David Bates, and Blackford Middleton at CITL. Health Affairs Web Exclusive, January 19, 2005.)

Financial Requirements for the Health Information Environment to be created and maintained:

• The Health Information Environment cannot and should not be built and funded independently of creating incentives for its use. If it is financed without corresponding changes to re-align incentives for its use, providers will remain unlikely to use the sub-networks to support patient care, crippling its success.
• The financial model must result from a combination of sustained public sector investment of core functions, seed funding for novel components and must also result from significant and sustained commitments of private capital.
• The early phase of the Health Information Environment, which could be considered the “build” phase, should include financing for the following activities:
1. The creation of the SPE and the initial development of the Common Framework
2. Seed funding of a critical mass of sub-networks that conform to the Common Framework
3. Financial incentives to providers to adopt HIT that conforms to the Common Framework and to participate in the sub-networks.

Each of the components of the “build phase” is elaborated below:

1. Funding the SPE:
• The SPE must be established and funded as soon as possible in order to continue the work of defining the Common Framework according to which all the sub-networks will operate. Once the initial set of standards and policies are in place, the Health Information Environment will grow and evolve organically and continually.
• The SPE will operate indefinitely and continually refine and evolve the policies and standards and therefore must also be funded as part of the continuing operation of the Health Information Environment.
• The SPE must have a secure funding source and be subject to public sector oversight to insure continuity of governance of the Health Information Environment. Core funding may be provided by DHHS but private sector contributions should provide a significant proportion of total support over time.
• The SPE may be an existing organization or a new organization modeled after other quasi-governmental or public-private organizations. Immediate, near-term efforts need to include an analysis of both the public and private sectors for viable models. These efforts should be completed in no more than one year. The analysis of organizational models could be conducted by the Institute of Medicine (IOM), an agency of the NRC such as the CSTB, a new specially appointed Commission/Task Force, or other existing entity with the appropriate stature and credibility.
2. Seed Funding of the Sub-networks:
   • As a general principle, the sub-networks must be self-funded and self-sustaining.
   • In order to “prime the pump”, accelerate early growth, and demonstrate early success of the Health Information Environment, government grants should be provided as seed funding to a selected group of sub-networks. This has already begun with the initial AHRQ grants.
   • Given the intended national scope of the regional sub-networks, significantly more capital will be needed for start-up grants than has recently been made available.
   • Recipients of such start-up grants must agree to use the Common Framework and to create requirements for participants within their network to do so. They must, in addition, adopt policies that reflect the public interest including equitable access, participation in governance and policy making, consumer and professional outreach, and transparency.
   • A financing model will need to be developed to provide startup and operations support for traditionally underserved communities of interest like those described in question 11.
   • To assist with seed-funding of the sub-networks, a range of capital financing vehicles could be employed, including grant funding, long-term revolving loan funds and tax credits to investors. Such funds could come from a wide range of sources, including various public and private sector funds and vehicles. Government participation in the seeding of these activities is critical and will accelerate private sector investment. In addition to direct funding, the Government’s provision of guarantees of bond issuances or loans can also facilitate private sector investment.
   • All healthcare stakeholders that benefit from the sub-network should work together to assure sustainability and appropriate funding. Costs that could be covered by the model might include those related to the Record Locator Service, community governance, and other community-based operational HIT components.

3. Financial Incentives for adoption of interoperable HIT:
• Financial incentives to providers for the adoption of HIT that conforms to the Common Framework will be among the factors leading to a critical mass of participants in the early phase of the Health Information Environment.
• Community consortia of public and private payers and purchasers, working in partnership with CMS and other major payers, should share ideas and early findings regarding effective incentive models. Such incentives may reward those clinicians who successfully adopt and use HIT to improve quality performance, and actively participate in the appropriate sub-networks.
• Incentive arrangements for HIT adoption must recognize that a critical mass of funding must be available to reduce "free ride" potential in which some organizations forgo participation yet reap the benefits.
• To further reduce “free ride” potential, it will be the responsibility of the Sub-Network Organizations to:
  • Work with community payers, purchasers and providers to discuss participation, incentives and appropriate funding models.
  • Monitor relevant stakeholder participation regarding conformance with the Common Framework and adoption incentives.

Question 6. What kind of financial model could be required to operate and sustain a functioning NHIN? Please describe the implications of various financing models.

Question 7. What privacy and security considerations, including compliance with relevant rules of HIPAA, are implicated by the NHIN, and how could they be addressed?

• All of the capabilities of the Health Information Environment including the delivery of care, the conduct of research, and public health reporting, must be conducted in an environment of trust, consistent with appropriate requirements for patient privacy, security, confidentiality, integrity, audit and informed consent.
• Participation in the Health Information Environment by providers, patients, or others must be voluntary; no one must be required to share information.
• The Health Information Environment is premised on a model of patient authorization and control. Patients must be able to: choose whether or not to participate in sharing personally identifiable information; exercise their rights under HIPAA; control who has access to their records (whether in whole or in part); see who has accessed their information; review, contribute to and amend their records (without unreasonable fees); receive paper or electronic copies of their information; and reliably and securely share all or portions of their records among institutions. Once patient consent has been granted for a certain type of information access, however, information should be able to be accessed freely in a trusted environment.
• Clinical data will be managed by those who have a direct relationship with the patient (patients may also keep their own records of their own information).
• No mandated national unique health ID is required, but standardized methodologies to identify patients are required.
• No single repository is intended to hold all of a patient’s clinical data (although this does not preclude patients from aggregating their data, either on their own or through the services of a trusted third party such as a personal health record or PHR provider).
• Authorization and authentication of users takes place at the regional, sub-network or local institution level.
• Sub-networks will be required to participate in some form of validation process.
• The Health Information Environment is a network of networks, linked only by registries through which authorized information about how to find the locations of records can be found, not any of the actual content of the health records. Thereby, the registry system knows only where records are, not what is in them.
• To achieve these capabilities, the Health Information Environment requires the addition of one new piece of infrastructure at the sub-network level based on an architecture that separates the function of locating authorized records from the function of transferring them to authorized users. This piece of infrastructure is the Record Locator Service (RLS) and is operated by a multi-stakeholder collaborative at the regional or non-geographic sub-network level and built on the current enterprise use of Master Patient Indices. The RLS itself is subject to privacy and security requirements, and is based on open standards set by the SPE.
• The system supports
  1. Linking of records via a registry of names and record location information, and sharing among users participating in the system, but it also allows
  2. Linking without sharing, or sharing pursuant only to higher authorization, as well as
  3. The ability to choose not to link information in certain sensitive treatment situations determined by users.
  By leaving these decisions at the edges (e.g., with patients and the professionals that support them), the architecture supports a range of approaches. It also allows higher levels of approval to be set locally for sharing some records. This obviates the need to have “one size fits all” policies as would be necessary for centrally controlled approaches. 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.
• The Privacy and Security Principles (as outlined by Connecting for Health’s Linking Workgroup) for the sub-networks and the broader Health Information Environment must address:
1. Confidentiality: Material existing within the system will only be disclosed to those authorized to have it.
2. Authentication: The system will require identification for use by all authorized individuals, thus both deflecting unauthorized use and enabling auditing for monitoring of compliance with policy guidelines.
3. Integrity: Material in the system will be defended against unauthorized alteration, and all alterations will be logged.
4. Non-repudiation: Transactions undertaken in the system will be acknowledged by both parties, and cannot be unilaterally revoked or altered.
• The Security Standards (as outlined by Connecting for Health’s Working Group on Accurately Linking Information for Health Care Quality and Safety in its report: Linking Healthcare Information: Proposed Methods for Improving Care and Protecting Privacy) must address:
1. Wire Security: Securing material “on the wire” means making sure that in its transit from point A to point B it is defended from eavesdropping, copying, or other interception. In practice, this can mean encrypting all the material passing over that connection, and ensuring that it is effectively delivered to the desired recipient.
2. Perimeter Security: Perimeter security involves requiring some form of authorization credentials for anyone using the system for any reason, as well as an auditing program that allows use of the system to be evaluated later.
3. Content Security: Sometimes a user is both authorized to use the system and a malefactor, as with the hypothetical examples of a file clerk searching for his girlfriend’s records, or the intern looking at the records of a famous patient. This type of attack can be limited by restricting what can be done with the data, even by authorized personnel, and by making sure that physical access to the equipment does not translate directly to access to its contents.

Question 8. How could the framework for a NHIN address public policy objectives for broad participation, responsiveness, open and non-proprietary interoperable infrastructure?

The Five Critical Key Components of the Health Information Environment, when taken together, will address public policy objectives for broad participation, responsiveness and the creation of a non-proprietary interoperable infrastructure. The Five Critical Components are:

1. The establishment of the Standards and Policy Entity (SPE) – (More fully described under Question 4). The SPE is a public-private collaborative entity that identifies and recommends the detailed implementation rules for the standards and policies that make up the Common Framework. The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE. The SPE operates and is funded without dependence on any one stakeholder group. It is transparent, accountable, and reflects the participation of all stakeholders, including the public. The SPE offers essential guidance – to encourage an innovative marketplace, regional control, and minimum redundancy or rework. While actively identifying and responding to new needs and the lessons of experience, the SPE is above all pragmatic, offering practical tools to address the most pressing priorities.
2. The creation of multi-stakeholder, collaborative, public interest Sub-Network Organizations at the regional or the non-geographic “sub-network level” that facilitate the development, implementation, and application of secure health information access by establishing and overseeing the sub-networks’ governance and operation (including the Record Locator Service).
3. Financial and non-financial incentives to increase HIT adoption by clinicians and other information suppliers and users and to encourage their connectivity consistent with the Common Framework. These incentives may include loans, grant funding and private and public investment through reimbursement changes. Three tiers of funding and incentives need to be in place to build the Health Information Environment:
1. Providing support for ongoing investment in the Common Framework and the standards and policies created and maintained by the SPE
2. Providing sufficient funding to seed the creation of self-sustaining regional initiatives consistent with the Common Framework.
3. Accelerating the adoption of electronic health record systems that adhere to the Common Framework, and that promote high quality healthcare based on greater access to health information.
4. A mechanism for validating compliance with the SPE Common Framework and standards. Early in the evolution, a separate private sector mechanism that may or may not be distinct from the SPE, is needed for validating compliance with the SPE Common Framework and standards and policies. Ultimately the network effect may create a mechanism for self-enforcing compliance. The method for validation must encourage, not deter, new entrants to the health IT market for tools and services to encourage competition and innovative business models.
5. Special attention must be given to underserved communities to ensure that they receive additional support and that they are mandatory, early participants in community-based initiatives and sub-networks. As with other health policy issues that affect underserved populations, government funding may be necessary to support this goal. See further elaboration under Question 3.

Management and Operational Considerations

Question 9. How could private sector competition be appropriately addressed and/or encouraged in the construction and implementation of a NHIN?

• The private sector is best at finding different market niches (clinics, hospitals, labs) and offering those markets products and services driven by different competitive strategies (mass production at low cost; high customization and ongoing services, etc.).
• Historically, the private sector has also advanced national interests when the goods and services on offer share a small but critical set of standards. The growth of the railroad industry was helped by standardization of track gauges; prior to those standards, a train from heading west from New York would have to unload its passengers and freight at St. Louis in order to change trains running on a different gauge track. Once the track gauges were standardized, the transport market for both goods and people became national, and, not coincidently, entered a period of rapid growth. At the turn of the last century, a raging fire broke out in a Baltimore warehouse. When firefighters from neighboring towns arrived to help, they discovered that their hoses would not fit the Baltimore hydrants. The catastrophic losses from the fire led to national standards for basic firefighting equipment.
• In the more recent domain of IT networks, the effect of simple standardization leading to expanding markets for interoperable tools is not only common but cumulative. The Internet created interoperability between computers made by different companies, something we take for granted today but which was novel in 1969.
• It worked as well as it did because the standards were minimal, creating basic interoperability but allowing different vendors to sell additional features above the core interoperability. For instance, once the basic standards of Internet transport were defined, the invention of e-mail turned the Internet into a communications channel. And once the basic e-mail headers were defined, any two systems using standards-compliant e-mail could trade messages, but each of those systems could have different ways of storing, sorting, and presenting those messages. The basic standards catalyzed the market, while allowing competition and continuous improvement for value-added features.
• The Web followed the same path, in which a handful of basic standards for requesting and displaying Web pages led to a proliferation of Web sites— media outlets, community hubs, commercial centers, and so on. The explosion of diversity on the Web, expanding to this day, is built on the simple standards for transport (http) and markup (HTML). Now Web Services, a set of methods for allowing automated transactions between machines, is repeating the pattern yet again, with a small set of markup standards such as the Simple Object Access Protocol (SOAP) that is creating a market for a huge variety of services. And of course Web Services is built on the Web which is built on the Internet.
• Without standards, competition subdivides customers into isolated camps, preventing the virtuous circle of network effects and returns to scale. When there is a minimal but essential set of standards, however, competition moves to price, features, and service, while preserving the interoperability that makes the market grow for everyone.
• In addition to improving outcomes in healthcare, uniform standards are of paramount importance to the adoption of healthcare IT, because those standards will give healthcare CIOs and other decision makers confidence in buying products, and because vendors will have an incentive to offer features and services above the baseline standards. The Health Information Environment must be based on such an essential set of standards, developed in partnership with the industries that will adopt them. The development of these standards must be hosted by a nationally accredited organization using an open and consensus-based process.
• In order to provide confidence to the eventual buyers and to enable the broadest possible deployment, these standards must be developed to work in the broadest range of technological environments, from the very simple to the very complex, and without making any particular vendor’s product or service a requirement for participation in the Health Information Environment.

Question 10. How could the NHIN be established to maintain a health information infrastructure that:

1. evolves appropriately from private investment;
2. is non-proprietary and available in the public domain;
3. achieves country-wide interoperability; and
4. fosters market innovation

• Facilitates and structures connectivity.
• Builds on the Internet and other existing networks without “new wires”.
• Provides the capabilities to support near real-time information access when essential for routine and emergency clinical care and also supports ongoing monitoring of disease outbreaks and threats of bioterrorism, research, and quality improvement.
• Leverages existing (and upcoming) open, non-proprietary standards for data content and transmission.
• A national Common Framework supports and guides all participation. The Common Framework consists of the technical and policy standards essential to ensure interoperability, serve the patients whose data it exchanges, and connect systems of varying technical sophistication.
• A Standards and Policy Entity (SPE) identifies and recommends standards and policies for the Common Framework, to be used to meet the ongoing requirements for interoperability.
• Governance is transparent and accountable and includes consumer, patient, and other stakeholder representation at all levels.
• Connectivity respects and serves patients and is built on the premise of patient control and authorization.
• Data is decentralized – stays where captured.
• Connectivity is achieved through a federated structure for policies, procedures, and standards.
• Patient identification is based on standardized methodologies but without a mandated national unique health identifier.
• Record Locator Services (RLS), situated in regional or other sub-networks, are new infrastructure components.
• The “build” of the new information environment happens incrementally, through accretion of sub-networks.
• A mechanism for validating compliance with the standards of the Common Framework is required for the early phases (there is uncertainty about how long this may be necessary), but the network eventually becomes self-validating.
• Privacy and security are among the primary design considerations.
• The Health Information Environment facilitates growth, innovation and competition in private industry.
• Health IT financing is multi-stakeholder with public and independent funding for the national SPE, seed grants and funding for the RLS and regional startups, and the incentives built into routine payment and operations at the regional and local level are tied to the use of the Common Framework.
• The information environment provides financial value to the entire health enterprise. The value that is generated ultimately funds the financial incentives for performance and stimulates the availability of private capital.

Question 11. How could a NHIN be established so that it will be utilized in the delivery of care by healthcare providers, regardless of their size and location, and also achieve enough national coverage to ensure that lower income rural and urban areas could be sufficiently served?

On the specific issue of minimizing capital requirements:

• It is paramount that the Health Information Environment be developed with as little overhead as possible and without ripping and replacing existing infrastructure.
• The development of the Health Information Environment must be done as cost-effectively as possible and therefore minimize the opportunity to create unnecessary “tolls” or barriers since the case for health information access already suffers from misaligned incentives.

On the specific issue of designing with flexibility of users and functionality in mind:

• Participation in the Health Information Environment must allow connectivity with a fairly low level of technical sophistication—the provider without an EHR should be able to receive value from the Health Information Environment with only an Internet browser. The approach outlined in this response takes into account three critical elements that create significant flexibility for users and functions:
1. First, it is heterogeneous with regard to the types of technology and function of the sub-networks and other entities that use it, providing that all of them adhere to the Common Framework. This enables users of varying levels of technical and functional sophistication to use it for a variety of processes.
2. Second it is flexible in that it facilitates communication among end-point systems at varying levels of sophistication in the structured and coded representation of data and supports the evolution of systems in this regard. For example, while some might use the Health Information Environment to locate records and request them by telephone, others may draw on it to support the full electronic exchange of highly structured data for sophisticated data analysis and decision support. This is necessary because health information will continue to be a mix of unstructured and structured and coded data. The Common Framework provides standards and procedures that allows two systems that support highly coded data to exchange it without loss of data, a system that supports less or little coding to receive information from comparable and from highly structured systems, and a system that supports a high level of coding to receive, file, and make use of lightly coded data when this comes from another system.
3. Lastly, the Health Information Environment is flexible also in that it is able to evolve over time to address the changing needs of users and to increase in scale as the numbers of users and their transactions grow; it supports a reasonable level of variation and innovation in response to local needs.

On providers and communities that require special attention:

• Broadband access and alternate connectivity approaches must be contemplated in rural and underserved communities.
• The use of incentives, grants and loans will drive the development of the Health Information Environment—underserved, rural and other communities will require a higher level of support, planning and special assistance with the formation of Sub-Network Organizations to include safety net providers is paramount.
• Specialized support centers or “help desks” familiar with the particular concerns of underserved and rural communities should provide support for them. Public and/or private financial support should be made available for these centers.
• The establishment of a Common Framework has the potential to reduce administrative and overhead costs in the healthcare system.

Question 12. How could community and regional health information exchange projects be affected by the development and implementation of a NHIN? What issues might arise and how could they be addressed?

• Community and regional health information projects could become part of the Health Information Environment by adhering to the “Common Framework”—the Health Information Environment is built on the success of sub-networks regionally or otherwise defined. Immediate action should be taken to identify and disseminate the requirements of the Common Framework.
• Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
• However, the complete approach articulated in this response is built upon the premise that “ripping and replacing” existing infrastructure is not an option and that creating flexibility in its design was paramount.
• The approach outlined in this response takes into account three critical elements that create significant flexibility for users and functions:
1. First, it is heterogeneous with regard to the types of technology and function of the sub-networks and other entities that use it, providing that all of them adhere to the Common Framework. This enables users of varying levels of technical and functional sophistication to use it for a variety of processes.
2. Second it is flexible in that it facilitates communication among end-point systems at varying levels of sophistication in the structured and coded representation of data and supports the evolution of systems in this regard. For example, while some might use the Health Information Environment to locate records and request them by telephone, others may draw on it to support the full electronic exchange of highly structured data for sophisticated data analysis and decision support. This is necessary because health information will continue to be a mix of unstructured and structured and coded data. The Common Framework provides standards and procedures that allows two systems that support highly coded data to exchange it without loss of data, a system that supports less or little coding to receive information from comparable and from highly structured systems, and a system that supports a high level of coding to receive, file, and make use of lightly coded data when this comes from another system.
3. Lastly, the Health Information Environment is flexible also in that it is able to evolve over time to address the changing needs of users and to increase in scale as the numbers of users and their transactions grow; it supports a reasonable level of variation and innovation in response to local needs.
• The Health Information Environment could point to and/or develop a sharing mechanism/resources whereby community and regional health information exchange projects could share their models and approaches with more fledgling projects. The newly created Resource Center funded by AHRQ can be leveraged to fulfill this important function.

Question 13. What effect could the implementation and broad adoption of a NHIN have on the health information technology market at large? Could the ensuing market opportunities be significant enough to merit the investment in a NHIN by the industry? To what entities could the benefits of these market opportunities accrue, and what implications (if any) does that have for the level of investment and/or role required from those beneficiaries in the establishment and perpetuation of a NHIN?

• Markets will be created when the need to access health information for high quality healthcare is aligned with financial incentives that encourage it.
• Great care should be taken to establish a level playing field in this market by not creating undue barriers to entry or by stifling innovation and competition. The approach outlined here will accomplish these goals.
• Broad adoption of electronic connectivity will produce market opportunities related to the adaptation and reengineering of workflow.
• While attempting to create new markets, it is important that the Health Information Environment not be used as a method to selectively steer commercial interests to the point of care in an unrestricted way or in a way that alters the neutrality of the infrastructure.
• In the long term there are likely to be significant market opportunities including the development of new and nascent products and services such as the PHR, telemedicine/telehealth, “smart” environments that monitor health data, and personalized medicine and genomics.

Standards and Policies to Achieve Interoperability

Question 14. What kinds of entity or entities could be needed to develop and diffuse interoperability standards and policies? What could be the characteristics of these entities? Do they exist today?

• Given the unusually sensitive nature of health information and the complexity of the technical standards and policies needed to guide its use, it is imperative that a single entity – the SPE – be responsible for decisions related to both domains so that they can be closely integrated. While the SPE must be the authority regarding matters in both domains, it may delegate pieces of its work requiring particular expertise to other entities.
• Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
• We propose the establishment of a Standards and Policy Entity (SPE – fully described under Question 4). The SPE is a public-private collaborative entity that identifies and recommends the detailed implementation rules for the standards and policies that make up the Common Framework. The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE. The SPE operates and is funded without dependence on any one stakeholder group. It is transparent, accountable, and reflects the participation of all stakeholders, including the public. The SPE offers the essential guidance – to encourage an innovative marketplace, regional control, and minimum redundancy or rework. While actively identifying and responding to new needs and the lessons of experience, the SPE is above all pragmatic, offering practical tools to address the most pressing priorities.

Question 15. How should the development and diffusion of technically sound, fully informed interoperability standards and policies be established and managed for a NHIN, initially and on an ongoing basis, that effectively address privacy and security issues and fully comply with HIPAA? How can these standards be protected from proprietary bias so that no vendors or organizations have undue influence or advantage? Examples of such standards and policies include: secure connectivity, mobile authentication, patient identification management and information exchange.

First, the Common Framework must be defined and specified. Without this, every entity that has to interact with the network will be unable to do so reliably and consistently— multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.

• 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.
• The technical standards address secure transport over the Internet and other networks, and provide the essential required components for the infrastructure including secure connectivity, reliable authentication and a suite of defined interchange formats for health care data.
• The policy standards address the privacy, use and access policies for the exchange of health information.
• The Common Framework also provides a uniform methodology for the identification of users.
• The modular character of the Common Framework permits rapid attainment of an interoperable information environment using essential requirements but also scales to a more complete structured data interchange for enhanced performance. The suite of interoperability standards will be enhanced over time.
• The Common Framework is the basis of all subsequent use cases that require specific, uniform interoperable standards to support information exchange. Use cases and accompanying information standards will be specified for each of the myriad of health information exchange requirements and will be supported by detailed implementation guides.
• The Common Framework should be required across all health communities, including the clinical research community, public health, etc.
• The participants in sub-networks will determine which profiles are appropriate to address the requirements established by their stakeholders.
• The Common Framework, and mechanisms to enforce compliance with it, ensures the creation, interoperability, scalability, efficiency and ongoing evolution of this environment. The Common Framework was further described in previous sections.

Second the SPE must be created to develop, maintain and disseminate the Common Framework and the suite of profiles for interoperability.

• The SPE (fully described under Question 4) is a public-private collaborative entity that identifies and recommends the detailed implementation rules for the standards and policies that make up the Common Framework.
• The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE.
• The SPE operates and is funded without dependence on any one stakeholder group. It is transparent, accountable, and reflects the participation of all stakeholders, including the public.
• The SPE offers the essential guidance – to encourage an innovative marketplace, regional control, and minimum redundancy or rework.
• While actively identifying and responding to new needs and the lessons of experience, the SPE is above all pragmatic, offering practical tools to address the most pressing priorities.

Each sub-network should collaborate with the SPE in the identification, interpretation, and development of standards and policies. Standards development organizations should participate with the SPE to develop new or modified standards, as requirements become known. The information technology industry should develop and promote cost-effective healthcare software and technologies that comply with the Common Framework. Financial incentives, loan opportunities, and IT procurement requirements, whether private or public, should be tied to compliance with the Common Framework and the policies and standards of the SPE.

Question 16. How could the efforts to develop and diffuse interoperability standards and policy relate to existing Standards Development Organizations to ensure maximum coordination and participation?

• The work contemplated by the Common Framework is not currently addressed by any one SDO.
• Existing SDOs will need to be responsive to the SPE and cooperative in helping to close gaps, agree to necessary development cycles and evolving requirements created by the Health Information Environment.
• Existing information standards should be used wherever possible, and internationally accepted information standards should be favored.

Question 17. What type of management and business rules could be required to promote and produce widespread adoption of interoperability standards and the diffusion of such standards into practice?

Two key components of the Health Information Environment taken together define the management and business rules that produce this result:

1. Management and business rules must adhere to the standards and policies defined by the SPE.
2. They are agreed to and enforced through the Sub-Network Organizations that oversee the health information environment. Some sub-networks will be geographically based and others will be functional or organizational, crossing geographical boundaries. The responsibilities of the Sub-Network Organizations include:
1. Establishing a multi-stakeholder governance structure that includes the representation of patients and consumers and safety net providers. The governance structure should be formalized and address the corporate and tax status of the Sub-Network Organization, its business plan and budget, intellectual property ownership and management, the entity’s statement of purpose and objectives, its decision making model, and its long-term strategic plan. Various types of governance model are acceptable.
2. Defining and meeting the particular information access needs of the region or sub-network while addressing the needs of patient populations that cross multiple communities nationwide or are contiguous but cross state lines.
3. Organizing the creation of “Articles of Federation” and other user agreements. A common set of multi-lateral policies, procedures, and standards to facilitate reliable, efficient sharing of health data among authorized users is required. The participating members of the health network must belong to and comply with agreements of a federation. Formal federation with clear agreements allows participants to access information that they have been authorized to share.
4. Supervising uniform adoption of information sharing policies or Articles of Federation by participating entities and mechanisms for their enforcement (e.g. sanctions).
5. Developing policies to address the need for retention and persistence of data.
6. Addressing conflicts among relevant stakeholders in a timely way.
7. Building, maintaining and managing the regional Record Locator Services and other sub-network systems and services.
8. Assuring that sub-network systems and the end-point systems of their members (including the Record Locator Service) adhere to the Common Framework.
9. Providing support to participants in the federation.
10. Establishing the financial sustainability models for the entity— responsibilities include:
11. Working with community payers, purchasers and providers to discuss participation, incentives and appropriate funding models.
12. Monitoring relevant stakeholder participation regarding conformance with the Common Framework and adoption incentives.
13. Ensuring that all of the information capabilities that define the Health Information Environment (including public health reporting and surveillance, research and improving health care quality) can be met over time.

• This approach should catalyze a market by creating a level playing field for market competition. Nevertheless, widespread clinical adoption will still depend on investment in the key components of the Health Information Environment and the re-alignment of incentives to reward and enable appropriate information use in clinical care.
• Incentives can include a wide variety of options from fundamental payment reform to eligibility for Federal assistance, eligibility to participate in federal demonstration projects, private-sector pay for performance incentives that require interoperability specified by the Common Framework, and eligibility to receive private IT adoption assistance.

Question 18. What roles and relationships should the federal government take in relation to how interoperability standards and policies are developed, and what roles and relationships should it refrain from taking?

• The federal government must play a central role in the Health Information Environment for it to succeed. That role includes:
• Taking a leadership role in creating incentives that are predicated on improving quality of care through IT
• Investing (with the private sector) in the creation of the SPE and providing seed funding to define and disseminate the Common Framework and the profiles for interoperability
• Medicare and Medicaid should coordinate their incentive structures, and should make sure they are compatible with incentives available to regional stakeholders.

Financial and/or Regulatory Incentives and Legal Considerations

Question 19. Are financial incentives required to drive the development of a marketplace for interoperable health information, so that relevant private industry companies will participate in the development of a broadly available, open and interoperable NHIN? If so, what types of incentives could gain the maximum benefit for the least investment? What restrictions or limitation should these incentives carry to ensure that the public interest is advanced?

• Yes, financial incentives are necessary for the Health Information Environment to be used as stated numerous times previously in this response.
• It would be unwise to establish a permanent payment system tied to IT adoption only; incentives for adoption should be time-limited to encourage rapid acquisition of “Common-Framework-enabled” applications that can connect and share data. Thereafter, funding should be incorporated within other payment methods.
• Maximum benefit for least investment would result from redesigning current fee-for-service reimbursement to include significant proportion of payment tied to validated health outcomes or evidence-based process measures.

Question 20. What kind of incentives should be available to regional stakeholders (e.g. health care providers, physicians, employers that purchase health insurance, payers) to use a health information exchange architecture based on a NHIN?

There are a variety of examples that merit further exploration:

• Pay for Performance incentives for improved outcomes based on validated measures and achieved as a result of health information access (e.g., avoidance of drug interaction by using the Health Information Environment for data access).
• Fund rapid experimentation with various models of reimbursement.
• Medicare and Medicaid should coordinate their incentive structures, and should make sure they are compatible with incentives available to regional stakeholders.
• Provide access to capital through low cost or government-backed revolving loans for EHR purchase.
• Develop a joint regional or national pool of funds to invest in clinical technology adoption by healthcare providers.
• Establish a matching grant program.
• Consider creative structuring to allow early transition from adoption-based to performance-based incentives, e.g., forgiving payments based on physicians meeting performance targets.
• Allow investment in EHR as a tax credit.
• (See “Financial, Legal and Organizational Approaches to Achieving Electronic Connectivity in Healthcare” at http://www.connectingforhealth.org/assets/reports/flo_sustain_healtcare_rpt.pdf for greater elaboration.)

Question 21. Are there statutory or regulatory requirements or prohibitions that might be perceived as barriers to the formation and operation of a NHIN, or to support it with critical functions?

• Legal safe harbors with restrictions
• Potential barriers that may be the result of inconsistency of state laws for healthcare information exchange need to be assessed.
• Healthcare payment policies and regulations that call for the inconsistent reporting of data or manipulation of codes representing healthcare data.
• Medical malpractice laws that may discourage physicians’ participation because of liability fears

Question 22. How could proposed organizational mechanisms or approaches address statutory and regulatory requirements (e.g. data privacy and security, antitrust constraints and tax issues)?

• The model proposed here would address issues regarding privacy and security, utilization of existing statutes such as HIPAA, use and access to information, business rules, and utilization of standards established in other domains to protect personal information.

Other

About the Health Information Environment

The Health Information Environment develops through the creation and connection of sub-networks that conform to the Common Framework of standards and policies.

• The quickest way to expand the Health Information Environment is by encouraging the parallel creation and connection of multiple sub-networks which all conform to the Common Framework.
• The Common Framework consists of the essential technical and policy requirements to enable the interoperation of standard interfaces and transactions at the local, regional and national level.
• Utilizing the Common Framework ensures economy of scale and speed of deployment and is essential because it enables the appropriate and necessary participation of national and super-regional entities (e.g., CMS, Kaiser, VA, etc.).

The Health Information Environment develops incrementally

• The Health Information Environment and the Common Framework that supports it should evolve over time and be responsive to new developments and ongoing innovation in technology and policy.

Healthcare applications are end-point systems connected to a “thin” Health Information Environment

• End-point systems include but are not limited to electronic health records, public health reporting systems, and other reporting systems.
• The Health Information Environment should facilitate the exchange of patient health information between end-point systems, or proxies for them, to improve the delivery of patient care and to further other health-related goals.
• The vendors or the operators of end-point systems support clinicians at varying levels of technology adoption (including those who do not yet have their own end-point systems) through “light” tools that offer clinicians Web-based information retrieval asymmetrically.
• A “thin” Health Information Environment builds upon the existing decentralized model and uses available Internet technologies.
• By utilizing existing Internet technologies, a “thin” Health Information Environment fosters increased competition and innovation by allowing industry efforts to focus on providing evolving healthcare-specific solutions.

Key to the Diagram

The Health Information Environment is a circular system; there is no “start” or “end” point because numerous transactions occur throughout it simultaneously. The following descriptions are of the elements portrayed in the diagram and the transactions associated with each of them. It is important to note that the diagram depicts one sub-network – many sub-networks of this type would be linked in an analogous fashion to comprise the full Health Information Environment. It is also important to highlight that all of the activities described by the diagram (excluding those of the end-point systems or applications) take place according to the guidelines set by the 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.

Common Framework

• The Common Framework specifies secure Internet based communication methods.
• Participants in the Health Information Environment are authenticated in a common fashion so that secure communications can occur.
• The Common Framework specifies information standards to allow unambiguous communication of clinical data.

Individual Care Providers

• Individual Care Providers, depicted by a circle on the left of the diagram, are the systems used by individuals or organizations to deliver or track care or health care operations.
• An Individual Care Provider system initiates an interaction with the Health Information Environment. For example, an authorized care professional might ask the Patient Index (also referred to as the Record Locator Service) whether there are any authorized records available that are necessary for the care of a patient (see the left side of the arc at the top of the diagram).
• An Individual Care Provider would use an end-point system or application – such as an electronic health record or providers’ portal via a thin web based client – as an interface to the Health Information Environment.

Patient Index (Record Locator Service)

• The Patient Index, also referred to as 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.
• The Patient Index (Record Locator Service), is at the top of the diagram. It contains a directory through which information about how to find the sources of authorized records can be found, not any of the actual content of the health records. The registry system knows where authorized records are, not what is in them.
• When an authorized Individual Care Provider submits a request to the Patient Index (Record Locator Service), it responds with information about the location (Data Sources or Information Sources) of any authorized and pertinent records (e.g. records for Jane Doe can be found at Hospital A and Lab B).

Message Transfer (Information Transfer)

• Message Transfer, (also described as Information Transfer), at the center of the diagram, is not an object, person, or institution, but an action—it represents what happens when one authorized part of the Health Information Environment shares authorized information with another.
• The standards and policies associated with the Common Framework include support for Message Transfer (Information Transfer).
• Message Transfer (Information Transfer) is initiated by a request from an Individual Care Provider directly to a Data Source (Information Source). The request could be made through a phone call, by paper, or electronically. The authorized information could be shared by fax, via a secure and standardized network connection using information standards defined by the Common Framework, or via paper.
• Requesting a Message Transfer (Information Transfer) of an actual record from a Data Source (Information Source) is an action distinct from requesting information from the Patient Index (Record Locator Service) about where records are located.
• When a provider retrieves data from another source to support a clinical decision the retrieved copy will usually become a part of the record maintained by the receiver.
• Message Transfer (Information Transfer) can also support anticipatory transfer of authorized patient information, including but not limited to distribution of lab results, referral reports, etc.

Data Sources (Information Sources)

• Data Sources, (also referred to as Information Sources), are the people or institutions that store health records. They are end-point systems supporting patients, providers, hospitals, diagnostic services, payers, or public health providers.
• When Data Sources (Information Sources) receive authorized requests for information from authorized Individual Care Providers, they send the appropriate records (a process described as Message Transfer or Information Transfer) – much as is done today.
• Data Sources (Information Sources) use end point systems or applications – such as electronic health records – as an interface to the Health Information Environment.
Data Sources (Information Sources) communicate regularly with the Patient Index (Record Locator Service) to make sure it is up to date about the availability of patient data, ideally registering this availability in “real time.”
• Data Sources (Information Sources) may also communicate with the Reporting Router as appropriate.

Reporting Router

• Reporting Router, at the bottom of the diagram, is an optional piece of infrastructure – a particular sub-network may choose whether or not to have one.
• The function of the Reporting Router is to find authorized identified or de-identified data appropriate for uses such as public health, quality improvement or research, and send or “push” it to the appropriate recipient (e.g. a public health agency, policy making body, research organization, etc).

Public Health

• Public Health, at the bottom left of the diagram, is an example of an entity, other than an Individual Care Provider, that may need access to health information.
• Public Health, like other users of the system, would access authorized information from the Health Information Environment via an end point system or application.

Example of How the Health Information Environment Works: Priscilla Switches Doctors

Above is an illustration of how linking, identification and transfer of a patient's records might happen. A patient, Priscilla Williams, moves and wants her new primary care physician at Clinic B, to have the results of her most recent pap smear, currently held at Clinic A. If her new physician can't get the results, she will have to take the test again, resulting in additional expense, difficulty, and delay.

Clinic A, a participant in the system, has provided the Record Locator Service with an authorized, updated list of patients it holds records on. This is a background process, where Clinic A communicates directly with the Record Locator Service at regular intervals, rather than part of the individual search transaction.

Once the staff of Clinic B has taken Priscilla’s identifying details (Transaction #1 above), they will authenticate themselves to the Record Locator Service (RLS) or to a local institution to allow for auditing. After they are authenticated, they will make a request for the location of any of Priscilla’s other authorized records.

The request from Clinic B to the RLS will travel over secure transport such as a Secure Socket Layers (SSL). On receiving it, the RLS will compare Pricilla’s information with their database. There are three possible outcomes here --the Record Locator Service finds records with such a high probability match that they can be identified as Priscilla's; it finds no records that match; or it finds records that might match, and asks Clinic B for more identifying information. (This third option would require staff allocated to handling such requests; some system designs may simply treat such ambiguous pairs as non-matches, to minimize human input, even at the expense of additional false negatives.)

Assuming there is a match, the RLS will return authorized pointers to other institutions such as Clinic A that hold her records (transaction #2 above). Clinic B will then make a request for Priscilla’s records directly to Clinic A, also via a secure internet connection, again providing authorization credentials to show that it is allowed to do so (transaction #3).

Some of the resulting authorized records may be returned from A to B directly over the Internet, using standardized interfaces for secure transport. The content of the messages may also be represented in a standardized format, for direct and automatic import into the new clinic’s database, while other records may be sent by secure email, or even simple fax. Once B has the results of her earlier pap smear (as well as any other records held by clinic A), the staff of Clinic B can then add them to Priscilla's file.

Question 24. How could success be measured in achieving an interoperable health information infrastructure for the public sector, private sector and health care community or region?

A comprehensive set of metrics should be established and tracked. Examples include:

• Ratio of users to potential users of the Health Information Environment
• Development and tracking of Healthcare Quality Indicators that derive from data access capability
• Speed with which outbreaks affecting the public’s health are identified
• Stable and secure coordination of key Health Information Environment functions
• Degree of interoperability across regional or other sub-networks
• Accountability to affected stakeholders, including effective independent review procedures
• Transparency, including procedural and financial transparency
• Financial metrics to evaluate the return on investment for each stakeholder.
• Representation of key interest groups, including the public interest representation
• Extent to which views of patients are taken into account in crafting policies and procedures relating to their rights and privacy
• Increased security of the root server system
• Support for long-term Internet and ICT evolution and innovation.
• Satisfaction of consumers with their health care system encounters
• Extent to which research and innovative approaches to prevention and treatment, (such as genetic treatment), are strengthened and made more cost-effective.
• Speed with which research results are integrated into health care and health-related decision-making.

APPENDIX A: Glossary of Key Terms

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 subnetworks 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.

APPENDIX B: Priority Areas for Continuing Work

Commercialization – While the development of some commercial applications that are integrated into the Health Information Environment is desirable and should be encouraged, it is important to differentiate and constrain those commercial uses that may hamper the ability of providers and patients to gain maximum benefit from access to clinical information, or compromise their trust. The Health Information Environment should not be used as a method to selectively steer commercial interests to the point of care in an unrestricted way or in a way that alters the neutrality of the infrastructure. Which types of commercial activity based on the Health Information Environment should be discouraged? Who should decide and how should this decision be enforced?

Finance – What is the best financial model to support the development and maintenance of the Health Information Environment? How should public and private funds be allocated? How should incentives for use of the environment be structured? What is the best model to support traditionally underserved communities?

Patient Control/Education – What are the implications of patient control of health information? What are the best ways to educate the public about how to use health information and ensure that patient consent to information exchange is meaningful? How should the public understand or engage with the Record Locator Service? What process and / or entities should carry out patient education, and how can multiple efforts best be coordinated?

Reconciliation of Potentially Conflicting State Laws – How do some state laws impede our ability to achieve vital national objectives? How should differences in state laws regarding access to or use of health information be addressed? What are the sources of leadership for reconciling state and federal legislation?

Standards and Policy Entity – The SPE may be an existing organization or a new organization modeled after other quasi-governmental or public-private organizations. Immediate, near-term efforts need to include an analysis of both the public and private sectors for viable models. These efforts should be completed in no more than one year. The analysis of organizational models could be conducted by the Institute of Medicine (IOM), an agency of the NRC such as the CSTB, a new specially appointed Commission/Task Force, or other existing entity with the appropriate stature and credibility.

Validation of Conformance and Interoperability – What processes should be used for validating compliance with the Common Framework? Should the mechanism be persistent? How should compliance be enforced?

• The Common Framework, and mechanisms to enforce compliance with it or other applicable standards and policies will be an essential condition of the development of the Health Information Environment. The Common Framework ensures the creation, interoperability, scalability, efficiency and ongoing evolution of this environment. Mechanisms to test and validate compliance may be necessary in several domains, including the “highest” or network environment level, the sub-network level, and the level of end point applications (e.g., EHRs). Validation methodologies should be appropriate to the information exchange, requiring only the elements and protocols essential to participation in the Health Information Environment, in a way that encourages innovation and new entrants to the market.
• An external mechanism for validating compliance with the standards of the Common Framework is required for the early phases, but the network may eventually become entirely self-validating. There is uncertainty about how long the outside compliance validation mechanism may be necessary—until the point at which there is a significant level of stability in the Health Information Environment. From the beginning, self-assessment should be built into the compliance validation mechanism because it helps to assure that programs are on track on a continuous basis, rather than waiting for an outside party to identify significant problems.
• Interface and transaction interoperability standards should allow for the appropriate and authorized integration of financial transaction information with related clinical transactional data.
• The Health Information Environment is inclusive of participants of varying levels of technical and functional sophistication. Its standards, rules and vocabularies can accommodate a wide variety of participants at any one time and can also be revised over time as user requirements evolve.

On the specific issue of market incentives and business objectives

• Healthcare suffers from a fragmented and stalled market for IT—both for connectivity and IT adoption generally.
• There is no “network effect” today in healthcare IT.
• The promulgation of a Common Framework will immediately accelerate the value of adopting IT by creating confidence in the ability of IT systems to reliably enable connectivity. Agreement on conformance validation mechanisms for interoperability will enhance this effect.
• This approach should catalyze a market by creating a level playing field for market competition. Nevertheless, widespread adoption of interoperable clinical IT will still depend on investment in the key components of the Health Information Environment and the use of incentives that recognize appropriate information use in clinical care.
• Incentives can include a wide variety of options from fundamental payment reform to eligibility for Federal assistance, eligibility to participate in federal demonstration projects, private-sector pay for performance incentives that require interoperability specified by the Common Framework, and eligibility to receive private IT adoption assistance.
• Incentives that reward the improved decision-making and quality of care enabled by the Health Information Environment will be more effective at driving participation than incentives tied specifically to IT adoption or network participation.

Question 3. What aspects of a NHIN could be national in scope vs. local or regional? Please describe the roles of entities at those levels.

• The Health Information Environment will take shape incrementally, over time. Its development will include both “top-down” (i.e., nationally-defined) policies and standards, and “bottom-up” (i.e., community and market-driven) initiatives.
• Both local and national strategies are needed. Most healthcare is local, and a great deal of information access occurs in a patient’s own community. At the same time, many patients receive care, coverage, and benefits across multiple regions; also, the US population is highly mobile, whether moving across state lines from home to work or from winter to summer homes. Many multi-institution networks, that effectively comprise local health information infrastructures, already exist and must be accommodated.
• In general our proposed model for the Health Information Environment is decentralized and regionally driven. It is desirable to leave to the local systems those things best handled locally, while specifying at a national level those things required as universal in order to allow for interoperability among regional systems. The Common Framework, comprised of the essential security and interoperability standards required to assure secure Internet transmission or patient matching methods, must be national, so that all participating institutions can connect to one another securely and without unworkable variation.

The various regional and national roles and entities for the Health Information Environment are:

• Each region or sub-network needs an entity (Sub-network Organization) to oversee its health information environment. Regional sub-networks have a public interest responsibility to address the needs of the entire population and all health information providers. Some sub-networks will be geographically based and others will be functional or organizational, crossing geographical boundaries. Some of these enterprise or private sub-networks (e.g., a large health system or research network) may not be subject to the same public interest governance and policy obligations. The responsibilities of the Sub-Network Organizations include:
1. Establishing a multi-stakeholder governance structure that includes the representation of patients and consumers and safety net providers. The governance structure should be formalized and address the corporate and tax status of the Sub-Network Organization, its business plan and budget, intellectual property ownership and management, the entity’s statement of purpose and objectives, its decision making model, and its long-term strategic plan. Various types of governance model are acceptable.
2. Defining and meeting the particular information access needs of the region or sub-network while addressing the needs of patient populations that cross multiple communities nationwide or are contiguous but cross state lines.
3. Organizing the creation of “Articles of Federation” and other user agreements. A common set of multi-lateral policies, procedures, and standards to facilitate reliable, efficient sharing of health data among authorized users is required. The participating members of the health network must belong to and comply with agreements of a federation. Formal federation with clear agreements allows participants to access information that they have been authorized to share.
4. Supervising uniform adoption of information sharing policies or Articles of Federation by participating entities and mechanisms for their enforcement (e.g. sanctions).
5. Developing policies to address the need for retention and persistence of data.
6. Addressing conflicts among relevant stakeholders in a timely way.
7. Building, maintaining and managing the regional Record Locator Services and other sub-network systems and services.
8. Assuring that sub-network systems and the end-point systems of their members (including the Record Locator Service) adhere to the Common Framework.
9. Providing support to participants in the federation.
10. Establishing the financial sustainability models for the entity— responsibilities include:
1. Working with community payers, purchasers and providers to discuss participation, incentives and appropriate funding models.
2. Monitoring relevant stakeholder participation regarding conformance with the Common Framework and adoption incentives.
11. Ensuring that all of the information capabilities that define the Health Information Environment (including public health reporting and surveillance, research and improving health care quality) can be met over time.
• In regions where there is low potential for an organizing function, (e.g., rural and underserved), other models of non-geographic sub-networks and Sub-Network Organizations should be established to support these necessary subnetworks. For example, there may be cases, especially in rural areas, where specialized clinical data repositories, or proxies, are shared by the providers in the community. Rural networks that may be meeting the needs of relatively closed provider networks may be best served by shared clinical data repositories that allow acceptable access speeds even when broadband Internet access is limited or less efficient. Any model must include the possibility for such clinical data repositories or proxies to exist as long as they comply with the Common Framework for interacting with other sub-networks as appropriate for patient care or other authorized use. Alternatively, some Sub-Network Organizations can explore potential partnerships with the appropriate State Health Departments, Medial Societies, NGOs, etc.

National

• A Standards and Policy Entity (SPE) to identify and recommend standards and policies for the “Common Framework”-a set of essential technical and policy requirements that enable the interoperation of standard interfaces and transactions at the local, regional and national level (more fully described in the next question).
• Privacy guidelines and policy clarification re: HIPAA, anti-kickback, potentially conflicting state laws and anti-trust laws.
• Performance and accountability metrics
• Experimentation with and creation of financial incentives that require the Common Framework
• Special attention, funding and mechanisms of support for rural and underserved communities
• Enforcement policies for misuse of data
• Coordinated efforts to ensure public understanding of the benefits of health information exchange and patients’ rights in the information exchange environment.

Organizational and Business Framework

Question 4. What type of framework could be needed to develop, set policies and standards for, operate, and adopt a NHIN? Describe the kinds of entities and stakeholders that could compose the framework and address the following components:

1. How could a NHIN be developed? What could be key considerations in constructing a NHIN? What could be a feasible model for accomplishing its construction?
2. How could policies and standards be set for the development, use and operation of a NHIN?
3. How could the adoption and use of the NHIN be accelerated for the mainstream delivery of care?
4. How could the NHIN be operated? What are key considerations in operating a NHIN?

• An over-arching principle in the development and operation of the Health Information Environment is the importance of serving the public interest: it must above all meet the needs of patients by enabling the provision of high quality care at reasonable costs.
• Consumer and patient advocates, amongst all other stakeholders, must be represented on an equal footing in the governance and advisory structure of all regional and national Health Information Environment authorities, including standard-selection and operational entities. Beyond this requirement, various governance models should be explored to balance stakeholder input while not becoming unduly burdensome.
• The Health Information Environment, like the Internet that functions as its core, will not be operated by a central entity. However, like the Internet, which has centralized functions such as domain name assignment, the Health Information Environment will require the centralization of some functions, such as those to be carried out by the Standards and Policy Entity described below.

The Five Critical Key Components of the Health Information Environment are:

1. The establishment of the Standards and Policy Entity (SPE):
   1. The SPE is a public-private collaborative entity that identifies and specifies the detailed implementation rules, including business rules, for the standards and policies that make up the Common Framework. It identifies and recommends the technical standards and information policies essential for establishing privacy, security and interoperability. The SPE is responsible for the identification, specification, interpretation, and dissemination of these standards and policies.
   2. Given the unusually sensitive nature of health information and the complexity of the technical standards and policies needed to guide its use, it is imperative that a single entity – the SPE – be responsible for decisions related to both domains so that they can be closely integrated. While the SPE must be the authority regarding matters in both domains, it may delegate pieces of its work requiring particular expertise to other entities. The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE.
   3. Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
   4. The SPE must not be disproportionately dependent on any of its stakeholders for its funding and must operate independently.
   5. The SPE requires public and private support.
   6. The SPE’s governance and administration must be transparent, accountable, and reflect the participation of all stakeholders, including representatives of the general public who are able to participate on an equal footing. The SPE administration includes a mechanism or formal process that reflects the participation of sub-networks and regional organizations.
   7. The SPE must protect the public good and ensure that consideration be given to enforcement functions.
   8. The SPE must be established and funded as soon as possible in order to continue the work of defining the Common Framework under which all the sub-networks will operate. Once the initial set of policies and standards are in place, and with proper incentives, the Health Information Environment will begin to grow and evolve organically and continually.
   9. The SPE must strive for maximum cost-effectiveness by building on existing standards and policy work (no “rip and replace”), establishing legitimate yet efficient processes and minimizing the negative economic impact of any new requirements it defines. As a general principle, the SPE should seek existing solutions and minimal modifications, creating new solutions only as a last resort. Even so, some change will be required to ensure interoperability across the boundaries of existing standards. The extent of such change must be determined using a defined process. To do so effectively requires close and continuous interaction with standards development organizations (SDOs) and other potential sources of relevant models for its own work.
   10. The requirements for interoperability will be specified in a suite of profiles or use cases defined and detailed by the SPE and premised on the Common Framework. The use cases will be specified via the selection of candidate suites or profiles of standards, for which detailed implementation and technical guides will be made available. The SPE must balance what is practical to implement with the needs of the nation.
   11. The SPE may be an existing organization or a new organization modeled after other quasi-governmental or public-private organizations. Immediate, near-term efforts need to include an analysis of both the public and private sectors for viable models. These efforts should be completed in no more than one year. The analysis of organizational models could be conducted by the Institute of Medicine (IOM), an agency of the NRC such as the CSTB, a new specially appointed Commission/Task Force, or other existing entity with the appropriate stature and credibility.
   12. The SPE must vigilantly guard against an accretion of duty or scope over time: its mission must always be to define and maintain the minimum framework necessary for the successful operation of the Health Information Environment.
2. The creation of multi-stakeholder, collaborative, public interest Sub-Network Organizations at the regional or the non-geographic “sub-network level” that facilitate the development, implementation, and application of secure health information access by establishing and overseeing the sub-networks’ governance and operation (including the Record Locator Service).
3. Financial and non-financial incentives to increase HIT adoption by clinicians and other information suppliers and users and to encourage their connectivity consistent with the Common Framework. These incentives may include loans, grant funding and private and public investment through reimbursement changes. Three tiers of funding and incentives need to be in place to build the Health Information Environment:
1. Providing support for ongoing investment in the Common Framework and the standards and policies created and maintained by the SPE
2. Providing sufficient funding to seed the creation of self-sustaining regional initiatives consistent with the Common Framework
3. Accelerating the adoption of electronic health record systems that adhere to the Common Framework, and that promote high quality healthcare based on greater access to health information.
4. A mechanism for validating compliance with the SPE Common Framework and standards. Early in the evolution, a separate private sector mechanism that may or may not be distinct from the SPE, is needed for validating compliance with the SPE Common Framework and standards and policies. Ultimately the network effect may create a mechanism for self-enforcing compliance. The method for validation must encourage, not deter, new entrants to the health IT market for tools and services to encourage competition and innovative business models.
5. Special attention must be given to underserved communities to ensure that they receive additional support and that they are mandatory, early participants in regional initiatives and sub-networks. In regions where there is low potential for an organizing function, (e.g., rural and underserved), other models of non-geographic sub-networks and Sub-Network Organizations should be established to support these necessary subnetworks. State Health Departments, medical societies, or other non-government organizations may be able to assist in these communities. As with other health policy issues that affect underserved populations, government funding may be necessary to support this goal. See further elaboration earlier in this draft.

Question 5. What kind of financial model could be required to build a NHIN? Please describe potential sources of initial funding, relative levels of contribution among sources and the implications of various funding models.

• We have prepared a single response to questions 5 and 6 because there is great overlap in the financial model to build the Health Information Environment and to operate and sustain it. There are, indeed, requirements in the early years that must precede other activities that could be considered a “build” period and these will be identified below. However, many of these same activities must persist throughout the lifetime of the Health Information Environment. Furthermore, “building” the Health Information Environment will continue indefinitely and the distinction between “building” and “operating and sustaining” the Health Information Environment will blur.

The Health Information Environment is premised on creation of value:

• The Health Information Environment development approach must create value for all of the stakeholders it connects, including (but not limited to) payers, providers, and consumers. It must build and sustain a robust marketplace for investment and continuous development of the infrastructure.
• The Health Information Environment creates value, and does not incur net, long-term costs for the federal government or other stakeholders.
• The Health Information Environment will create value by returning greater financial savings to U.S. society through use of HIT than the costs incurred through adoption of EHRs, the sub-networks of which they are part, and the support of the environment in which they operate. (See “Accelerating US EHR Adoption: How to Get There From Here, Recommendations Based on the 2004 ACMI Retreat” by Blackford Middleton, W. Ed Hammond, Patricia F. Brennan, and Gregory F. Cooper,, J Am Med Inform Assoc. 2005; 12: 1319.)
• Full systematic interoperability has been estimated to save $78 billion per year in the United States compared with current manual methods of data recording, re-recording and transport. (See "The Value of Health Care Information Exchange and Interoperability" by Jan Walker, Eric Pan, Doug Johnston, Julia-Adler Milstein, David Bates, and Blackford Middleton at CITL. Health Affairs Web Exclusive, January 19, 2005.)

Financial Requirements for the Health Information Environment to be created and maintained:

• The Health Information Environment cannot and should not be built and funded independently of creating incentives for its use. If it is financed without corresponding changes to re-align incentives for its use, providers will remain unlikely to use the sub-networks to support patient care, crippling its success.
• The financial model must result from a combination of sustained public sector investment of core functions, seed funding for novel components and must also result from significant and sustained commitments of private capital.
• The early phase of the Health Information Environment, which could be considered the “build” phase, should include financing for the following activities:
1. The creation of the SPE and the initial development of the Common Framework
2. Seed funding of a critical mass of sub-networks that conform to the Common Framework
3. Financial incentives to providers to adopt HIT that conforms to the Common Framework and to participate in the sub-networks.

Each of the components of the “build phase” is elaborated below:

1. Funding the SPE:
• The SPE must be established and funded as soon as possible in order to continue the work of defining the Common Framework according to which all the sub-networks will operate. Once the initial set of standards and policies are in place, the Health Information Environment will grow and evolve organically and continually.
• The SPE will operate indefinitely and continually refine and evolve the policies and standards and therefore must also be funded as part of the continuing operation of the Health Information Environment.
• The SPE must have a secure funding source and be subject to public sector oversight to insure continuity of governance of the Health Information Environment. Core funding may be provided by DHHS but private sector contributions should provide a significant proportion of total support over time.
• The SPE may be an existing organization or a new organization modeled after other quasi-governmental or public-private organizations. Immediate, near-term efforts need to include an analysis of both the public and private sectors for viable models. These efforts should be completed in no more than one year. The analysis of organizational models could be conducted by the Institute of Medicine (IOM), an agency of the NRC such as the CSTB, a new specially appointed Commission/Task Force, or other existing entity with the appropriate stature and credibility.
2. Seed Funding of the Sub-networks:
   • As a general principle, the sub-networks must be self-funded and self-sustaining.
   • In order to “prime the pump”, accelerate early growth, and demonstrate early success of the Health Information Environment, government grants should be provided as seed funding to a selected group of sub-networks. This has already begun with the initial AHRQ grants.
   • Given the intended national scope of the regional sub-networks, significantly more capital will be needed for start-up grants than has recently been made available.
   • Recipients of such start-up grants must agree to use the Common Framework and to create requirements for participants within their network to do so. They must, in addition, adopt policies that reflect the public interest including equitable access, participation in governance and policy making, consumer and professional outreach, and transparency.
   • A financing model will need to be developed to provide startup and operations support for traditionally underserved communities of interest like those described in question 11.
   • To assist with seed-funding of the sub-networks, a range of capital financing vehicles could be employed, including grant funding, long-term revolving loan funds and tax credits to investors. Such funds could come from a wide range of sources, including various public and private sector funds and vehicles. Government participation in the seeding of these activities is critical and will accelerate private sector investment. In addition to direct funding, the Government’s provision of guarantees of bond issuances or loans can also facilitate private sector investment.
   • All healthcare stakeholders that benefit from the sub-network should work together to assure sustainability and appropriate funding. Costs that could be covered by the model might include those related to the Record Locator Service, community governance, and other community-based operational HIT components.

3. Financial Incentives for adoption of interoperable HIT:
• Financial incentives to providers for the adoption of HIT that conforms to the Common Framework will be among the factors leading to a critical mass of participants in the early phase of the Health Information Environment.
• Community consortia of public and private payers and purchasers, working in partnership with CMS and other major payers, should share ideas and early findings regarding effective incentive models. Such incentives may reward those clinicians who successfully adopt and use HIT to improve quality performance, and actively participate in the appropriate sub-networks.
• Incentive arrangements for HIT adoption must recognize that a critical mass of funding must be available to reduce "free ride" potential in which some organizations forgo participation yet reap the benefits.
• To further reduce “free ride” potential, it will be the responsibility of the Sub-Network Organizations to:
  • Work with community payers, purchasers and providers to discuss participation, incentives and appropriate funding models.
  • Monitor relevant stakeholder participation regarding conformance with the Common Framework and adoption incentives.

Question 6. What kind of financial model could be required to operate and sustain a functioning NHIN? Please describe the implications of various financing models.

Question 7. What privacy and security considerations, including compliance with relevant rules of HIPAA, are implicated by the NHIN, and how could they be addressed?

• All of the capabilities of the Health Information Environment including the delivery of care, the conduct of research, and public health reporting, must be conducted in an environment of trust, consistent with appropriate requirements for patient privacy, security, confidentiality, integrity, audit and informed consent.
• Participation in the Health Information Environment by providers, patients, or others must be voluntary; no one must be required to share information.
• The Health Information Environment is premised on a model of patient authorization and control. Patients must be able to: choose whether or not to participate in sharing personally identifiable information; exercise their rights under HIPAA; control who has access to their records (whether in whole or in part); see who has accessed their information; review, contribute to and amend their records (without unreasonable fees); receive paper or electronic copies of their information; and reliably and securely share all or portions of their records among institutions. Once patient consent has been granted for a certain type of information access, however, information should be able to be accessed freely in a trusted environment.
• Clinical data will be managed by those who have a direct relationship with the patient (patients may also keep their own records of their own information).
• No mandated national unique health ID is required, but standardized methodologies to identify patients are required.
• No single repository is intended to hold all of a patient’s clinical data (although this does not preclude patients from aggregating their data, either on their own or through the services of a trusted third party such as a personal health record or PHR provider).
• Authorization and authentication of users takes place at the regional, sub-network or local institution level.
• Sub-networks will be required to participate in some form of validation process.
• The Health Information Environment is a network of networks, linked only by registries through which authorized information about how to find the locations of records can be found, not any of the actual content of the health records. Thereby, the registry system knows only where records are, not what is in them.
• To achieve these capabilities, the Health Information Environment requires the addition of one new piece of infrastructure at the sub-network level based on an architecture that separates the function of locating authorized records from the function of transferring them to authorized users. This piece of infrastructure is the Record Locator Service (RLS) and is operated by a multi-stakeholder collaborative at the regional or non-geographic sub-network level and built on the current enterprise use of Master Patient Indices. The RLS itself is subject to privacy and security requirements, and is based on open standards set by the SPE.
• The system supports
  1. Linking of records via a registry of names and record location information, and sharing among users participating in the system, but it also allows
  2. Linking without sharing, or sharing pursuant only to higher authorization, as well as
  3. The ability to choose not to link information in certain sensitive treatment situations determined by users.
  By leaving these decisions at the edges (e.g., with patients and the professionals that support them), the architecture supports a range of approaches. It also allows higher levels of approval to be set locally for sharing some records. This obviates the need to have “one size fits all” policies as would be necessary for centrally controlled approaches. 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.
• The Privacy and Security Principles (as outlined by Connecting for Health’s Linking Workgroup) for the sub-networks and the broader Health Information Environment must address:
1. Confidentiality: Material existing within the system will only be disclosed to those authorized to have it.
2. Authentication: The system will require identification for use by all authorized individuals, thus both deflecting unauthorized use and enabling auditing for monitoring of compliance with policy guidelines.
3. Integrity: Material in the system will be defended against unauthorized alteration, and all alterations will be logged.
4. Non-repudiation: Transactions undertaken in the system will be acknowledged by both parties, and cannot be unilaterally revoked or altered.
• The Security Standards (as outlined by Connecting for Health’s Working Group on Accurately Linking Information for Health Care Quality and Safety in its report: Linking Healthcare Information: Proposed Methods for Improving Care and Protecting Privacy) must address:
1. Wire Security: Securing material “on the wire” means making sure that in its transit from point A to point B it is defended from eavesdropping, copying, or other interception. In practice, this can mean encrypting all the material passing over that connection, and ensuring that it is effectively delivered to the desired recipient.
2. Perimeter Security: Perimeter security involves requiring some form of authorization credentials for anyone using the system for any reason, as well as an auditing program that allows use of the system to be evaluated later.
3. Content Security: Sometimes a user is both authorized to use the system and a malefactor, as with the hypothetical examples of a file clerk searching for his girlfriend’s records, or the intern looking at the records of a famous patient. This type of attack can be limited by restricting what can be done with the data, even by authorized personnel, and by making sure that physical access to the equipment does not translate directly to access to its contents.

Question 8. How could the framework for a NHIN address public policy objectives for broad participation, responsiveness, open and non-proprietary interoperable infrastructure?

The Five Critical Key Components of the Health Information Environment, when taken together, will address public policy objectives for broad participation, responsiveness and the creation of a non-proprietary interoperable infrastructure. The Five Critical Components are:

1. The establishment of the Standards and Policy Entity (SPE) – (More fully described under Question 4). The SPE is a public-private collaborative entity that identifies and recommends the detailed implementation rules for the standards and policies that make up the Common Framework. The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE. The SPE operates and is funded without dependence on any one stakeholder group. It is transparent, accountable, and reflects the participation of all stakeholders, including the public. The SPE offers essential guidance – to encourage an innovative marketplace, regional control, and minimum redundancy or rework. While actively identifying and responding to new needs and the lessons of experience, the SPE is above all pragmatic, offering practical tools to address the most pressing priorities.
2. The creation of multi-stakeholder, collaborative, public interest Sub-Network Organizations at the regional or the non-geographic “sub-network level” that facilitate the development, implementation, and application of secure health information access by establishing and overseeing the sub-networks’ governance and operation (including the Record Locator Service).
3. Financial and non-financial incentives to increase HIT adoption by clinicians and other information suppliers and users and to encourage their connectivity consistent with the Common Framework. These incentives may include loans, grant funding and private and public investment through reimbursement changes. Three tiers of funding and incentives need to be in place to build the Health Information Environment:
1. Providing support for ongoing investment in the Common Framework and the standards and policies created and maintained by the SPE
2. Providing sufficient funding to seed the creation of self-sustaining regional initiatives consistent with the Common Framework.
3. Accelerating the adoption of electronic health record systems that adhere to the Common Framework, and that promote high quality healthcare based on greater access to health information.
4. A mechanism for validating compliance with the SPE Common Framework and standards. Early in the evolution, a separate private sector mechanism that may or may not be distinct from the SPE, is needed for validating compliance with the SPE Common Framework and standards and policies. Ultimately the network effect may create a mechanism for self-enforcing compliance. The method for validation must encourage, not deter, new entrants to the health IT market for tools and services to encourage competition and innovative business models.
5. Special attention must be given to underserved communities to ensure that they receive additional support and that they are mandatory, early participants in community-based initiatives and sub-networks. As with other health policy issues that affect underserved populations, government funding may be necessary to support this goal. See further elaboration under Question 3.

Management and Operational Considerations

Question 9. How could private sector competition be appropriately addressed and/or encouraged in the construction and implementation of a NHIN?

• The private sector is best at finding different market niches (clinics, hospitals, labs) and offering those markets products and services driven by different competitive strategies (mass production at low cost; high customization and ongoing services, etc.).
• Historically, the private sector has also advanced national interests when the goods and services on offer share a small but critical set of standards. The growth of the railroad industry was helped by standardization of track gauges; prior to those standards, a train from heading west from New York would have to unload its passengers and freight at St. Louis in order to change trains running on a different gauge track. Once the track gauges were standardized, the transport market for both goods and people became national, and, not coincidently, entered a period of rapid growth. At the turn of the last century, a raging fire broke out in a Baltimore warehouse. When firefighters from neighboring towns arrived to help, they discovered that their hoses would not fit the Baltimore hydrants. The catastrophic losses from the fire led to national standards for basic firefighting equipment.
• In the more recent domain of IT networks, the effect of simple standardization leading to expanding markets for interoperable tools is not only common but cumulative. The Internet created interoperability between computers made by different companies, something we take for granted today but which was novel in 1969.
• It worked as well as it did because the standards were minimal, creating basic interoperability but allowing different vendors to sell additional features above the core interoperability. For instance, once the basic standards of Internet transport were defined, the invention of e-mail turned the Internet into a communications channel. And once the basic e-mail headers were defined, any two systems using standards-compliant e-mail could trade messages, but each of those systems could have different ways of storing, sorting, and presenting those messages. The basic standards catalyzed the market, while allowing competition and continuous improvement for value-added features.
• The Web followed the same path, in which a handful of basic standards for requesting and displaying Web pages led to a proliferation of Web sites— media outlets, community hubs, commercial centers, and so on. The explosion of diversity on the Web, expanding to this day, is built on the simple standards for transport (http) and markup (HTML). Now Web Services, a set of methods for allowing automated transactions between machines, is repeating the pattern yet again, with a small set of markup standards such as the Simple Object Access Protocol (SOAP) that is creating a market for a huge variety of services. And of course Web Services is built on the Web which is built on the Internet.
• Without standards, competition subdivides customers into isolated camps, preventing the virtuous circle of network effects and returns to scale. When there is a minimal but essential set of standards, however, competition moves to price, features, and service, while preserving the interoperability that makes the market grow for everyone.
• In addition to improving outcomes in healthcare, uniform standards are of paramount importance to the adoption of healthcare IT, because those standards will give healthcare CIOs and other decision makers confidence in buying products, and because vendors will have an incentive to offer features and services above the baseline standards. The Health Information Environment must be based on such an essential set of standards, developed in partnership with the industries that will adopt them. The development of these standards must be hosted by a nationally accredited organization using an open and consensus-based process.
• In order to provide confidence to the eventual buyers and to enable the broadest possible deployment, these standards must be developed to work in the broadest range of technological environments, from the very simple to the very complex, and without making any particular vendor’s product or service a requirement for participation in the Health Information Environment.

Question 10. How could the NHIN be established to maintain a health information infrastructure that:

1. evolves appropriately from private investment;
2. is non-proprietary and available in the public domain;
3. achieves country-wide interoperability; and
4. fosters market innovation

• Facilitates and structures connectivity.
• Builds on the Internet and other existing networks without “new wires”.
• Provides the capabilities to support near real-time information access when essential for routine and emergency clinical care and also supports ongoing monitoring of disease outbreaks and threats of bioterrorism, research, and quality improvement.
• Leverages existing (and upcoming) open, non-proprietary standards for data content and transmission.
• A national Common Framework supports and guides all participation. The Common Framework consists of the technical and policy standards essential to ensure interoperability, serve the patients whose data it exchanges, and connect systems of varying technical sophistication.
• A Standards and Policy Entity (SPE) identifies and recommends standards and policies for the Common Framework, to be used to meet the ongoing requirements for interoperability.
• Governance is transparent and accountable and includes consumer, patient, and other stakeholder representation at all levels.
• Connectivity respects and serves patients and is built on the premise of patient control and authorization.
• Data is decentralized – stays where captured.
• Connectivity is achieved through a federated structure for policies, procedures, and standards.
• Patient identification is based on standardized methodologies but without a mandated national unique health identifier.
• Record Locator Services (RLS), situated in regional or other sub-networks, are new infrastructure components.
• The “build” of the new information environment happens incrementally, through accretion of sub-networks.
• A mechanism for validating compliance with the standards of the Common Framework is required for the early phases (there is uncertainty about how long this may be necessary), but the network eventually becomes self-validating.
• Privacy and security are among the primary design considerations.
• The Health Information Environment facilitates growth, innovation and competition in private industry.
• Health IT financing is multi-stakeholder with public and independent funding for the national SPE, seed grants and funding for the RLS and regional startups, and the incentives built into routine payment and operations at the regional and local level are tied to the use of the Common Framework.
• The information environment provides financial value to the entire health enterprise. The value that is generated ultimately funds the financial incentives for performance and stimulates the availability of private capital.

Question 11. How could a NHIN be established so that it will be utilized in the delivery of care by healthcare providers, regardless of their size and location, and also achieve enough national coverage to ensure that lower income rural and urban areas could be sufficiently served?

On the specific issue of minimizing capital requirements:

• It is paramount that the Health Information Environment be developed with as little overhead as possible and without ripping and replacing existing infrastructure.
• The development of the Health Information Environment must be done as cost-effectively as possible and therefore minimize the opportunity to create unnecessary “tolls” or barriers since the case for health information access already suffers from misaligned incentives.

On the specific issue of designing with flexibility of users and functionality in mind:

• Participation in the Health Information Environment must allow connectivity with a fairly low level of technical sophistication—the provider without an EHR should be able to receive value from the Health Information Environment with only an Internet browser. The approach outlined in this response takes into account three critical elements that create significant flexibility for users and functions:
1. First, it is heterogeneous with regard to the types of technology and function of the sub-networks and other entities that use it, providing that all of them adhere to the Common Framework. This enables users of varying levels of technical and functional sophistication to use it for a variety of processes.
2. Second it is flexible in that it facilitates communication among end-point systems at varying levels of sophistication in the structured and coded representation of data and supports the evolution of systems in this regard. For example, while some might use the Health Information Environment to locate records and request them by telephone, others may draw on it to support the full electronic exchange of highly structured data for sophisticated data analysis and decision support. This is necessary because health information will continue to be a mix of unstructured and structured and coded data. The Common Framework provides standards and procedures that allows two systems that support highly coded data to exchange it without loss of data, a system that supports less or little coding to receive information from comparable and from highly structured systems, and a system that supports a high level of coding to receive, file, and make use of lightly coded data when this comes from another system.
3. Lastly, the Health Information Environment is flexible also in that it is able to evolve over time to address the changing needs of users and to increase in scale as the numbers of users and their transactions grow; it supports a reasonable level of variation and innovation in response to local needs.

On providers and communities that require special attention:

• Broadband access and alternate connectivity approaches must be contemplated in rural and underserved communities.
• The use of incentives, grants and loans will drive the development of the Health Information Environment—underserved, rural and other communities will require a higher level of support, planning and special assistance with the formation of Sub-Network Organizations to include safety net providers is paramount.
• Specialized support centers or “help desks” familiar with the particular concerns of underserved and rural communities should provide support for them. Public and/or private financial support should be made available for these centers.
• The establishment of a Common Framework has the potential to reduce administrative and overhead costs in the healthcare system.

Question 12. How could community and regional health information exchange projects be affected by the development and implementation of a NHIN? What issues might arise and how could they be addressed?

• Community and regional health information projects could become part of the Health Information Environment by adhering to the “Common Framework”—the Health Information Environment is built on the success of sub-networks regionally or otherwise defined. Immediate action should be taken to identify and disseminate the requirements of the Common Framework.
• Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
• However, the complete approach articulated in this response is built upon the premise that “ripping and replacing” existing infrastructure is not an option and that creating flexibility in its design was paramount.
• The approach outlined in this response takes into account three critical elements that create significant flexibility for users and functions:
1. First, it is heterogeneous with regard to the types of technology and function of the sub-networks and other entities that use it, providing that all of them adhere to the Common Framework. This enables users of varying levels of technical and functional sophistication to use it for a variety of processes.
2. Second it is flexible in that it facilitates communication among end-point systems at varying levels of sophistication in the structured and coded representation of data and supports the evolution of systems in this regard. For example, while some might use the Health Information Environment to locate records and request them by telephone, others may draw on it to support the full electronic exchange of highly structured data for sophisticated data analysis and decision support. This is necessary because health information will continue to be a mix of unstructured and structured and coded data. The Common Framework provides standards and procedures that allows two systems that support highly coded data to exchange it without loss of data, a system that supports less or little coding to receive information from comparable and from highly structured systems, and a system that supports a high level of coding to receive, file, and make use of lightly coded data when this comes from another system.
3. Lastly, the Health Information Environment is flexible also in that it is able to evolve over time to address the changing needs of users and to increase in scale as the numbers of users and their transactions grow; it supports a reasonable level of variation and innovation in response to local needs.
• The Health Information Environment could point to and/or develop a sharing mechanism/resources whereby community and regional health information exchange projects could share their models and approaches with more fledgling projects. The newly created Resource Center funded by AHRQ can be leveraged to fulfill this important function.

Question 13. What effect could the implementation and broad adoption of a NHIN have on the health information technology market at large? Could the ensuing market opportunities be significant enough to merit the investment in a NHIN by the industry? To what entities could the benefits of these market opportunities accrue, and what implications (if any) does that have for the level of investment and/or role required from those beneficiaries in the establishment and perpetuation of a NHIN?

• Markets will be created when the need to access health information for high quality healthcare is aligned with financial incentives that encourage it.
• Great care should be taken to establish a level playing field in this market by not creating undue barriers to entry or by stifling innovation and competition. The approach outlined here will accomplish these goals.
• Broad adoption of electronic connectivity will produce market opportunities related to the adaptation and reengineering of workflow.
• While attempting to create new markets, it is important that the Health Information Environment not be used as a method to selectively steer commercial interests to the point of care in an unrestricted way or in a way that alters the neutrality of the infrastructure.
• In the long term there are likely to be significant market opportunities including the development of new and nascent products and services such as the PHR, telemedicine/telehealth, “smart” environments that monitor health data, and personalized medicine and genomics.

Standards and Policies to Achieve Interoperability

Question 14. What kinds of entity or entities could be needed to develop and diffuse interoperability standards and policies? What could be the characteristics of these entities? Do they exist today?

• Given the unusually sensitive nature of health information and the complexity of the technical standards and policies needed to guide its use, it is imperative that a single entity – the SPE – be responsible for decisions related to both domains so that they can be closely integrated. While the SPE must be the authority regarding matters in both domains, it may delegate pieces of its work requiring particular expertise to other entities.
• Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
• We propose the establishment of a Standards and Policy Entity (SPE – fully described under Question 4). The SPE is a public-private collaborative entity that identifies and recommends the detailed implementation rules for the standards and policies that make up the Common Framework. The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE. The SPE operates and is funded without dependence on any one stakeholder group. It is transparent, accountable, and reflects the participation of all stakeholders, including the public. The SPE offers the essential guidance – to encourage an innovative marketplace, regional control, and minimum redundancy or rework. While actively identifying and responding to new needs and the lessons of experience, the SPE is above all pragmatic, offering practical tools to address the most pressing priorities.

Question 15. How should the development and diffusion of technically sound, fully informed interoperability standards and policies be established and managed for a NHIN, initially and on an ongoing basis, that effectively address privacy and security issues and fully comply with HIPAA? How can these standards be protected from proprietary bias so that no vendors or organizations have undue influence or advantage? Examples of such standards and policies include: secure connectivity, mobile authentication, patient identification management and information exchange.

First, the Common Framework must be defined and specified. Without this, every entity that has to interact with the network will be unable to do so reliably and consistently— multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.

• 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.
• The technical standards address secure transport over the Internet and other networks, and provide the essential required components for the infrastructure including secure connectivity, reliable authentication and a suite of defined interchange formats for health care data.
• The policy standards address the privacy, use and access policies for the exchange of health information.
• The Common Framework also provides a uniform methodology for the identification of users.
• The modular character of the Common Framework permits rapid attainment of an interoperable information environment using essential requirements but also scales to a more complete structured data interchange for enhanced performance. The suite of interoperability standards will be enhanced over time.
• The Common Framework is the basis of all subsequent use cases that require specific, uniform interoperable standards to support information exchange. Use cases and accompanying information standards will be specified for each of the myriad of health information exchange requirements and will be supported by detailed implementation guides.
• The Common Framework should be required across all health communities, including the clinical research community, public health, etc.
• The participants in sub-networks will determine which profiles are appropriate to address the requirements established by their stakeholders.
• The Common Framework, and mechanisms to enforce compliance with it, ensures the creation, interoperability, scalability, efficiency and ongoing evolution of this environment. The Common Framework was further described in previous sections.

Second the SPE must be created to develop, maintain and disseminate the Common Framework and the suite of profiles for interoperability.

• The SPE (fully described under Question 4) is a public-private collaborative entity that identifies and recommends the detailed implementation rules for the standards and policies that make up the Common Framework.
• The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE.
• The SPE operates and is funded without dependence on any one stakeholder group. It is transparent, accountable, and reflects the participation of all stakeholders, including the public.
• The SPE offers the essential guidance – to encourage an innovative marketplace, regional control, and minimum redundancy or rework.
• While actively identifying and responding to new needs and the lessons of experience, the SPE is above all pragmatic, offering practical tools to address the most pressing priorities.

Each sub-network should collaborate with the SPE in the identification, interpretation, and development of standards and policies. Standards development organizations should participate with the SPE to develop new or modified standards, as requirements become known. The information technology industry should develop and promote cost-effective healthcare software and technologies that comply with the Common Framework. Financial incentives, loan opportunities, and IT procurement requirements, whether private or public, should be tied to compliance with the Common Framework and the policies and standards of the SPE.

Question 16. How could the efforts to develop and diffuse interoperability standards and policy relate to existing Standards Development Organizations to ensure maximum coordination and participation?

• The work contemplated by the Common Framework is not currently addressed by any one SDO.
• Existing SDOs will need to be responsive to the SPE and cooperative in helping to close gaps, agree to necessary development cycles and evolving requirements created by the Health Information Environment.
• Existing information standards should be used wherever possible, and internationally accepted information standards should be favored.

Question 17. What type of management and business rules could be required to promote and produce widespread adoption of interoperability standards and the diffusion of such standards into practice?

Two key components of the Health Information Environment taken together define the management and business rules that produce this result:

1. Management and business rules must adhere to the standards and policies defined by the SPE.
2. They are agreed to and enforced through the Sub-Network Organizations that oversee the health information environment. Some sub-networks will be geographically based and others will be functional or organizational, crossing geographical boundaries. The responsibilities of the Sub-Network Organizations include:
1. Establishing a multi-stakeholder governance structure that includes the representation of patients and consumers and safety net providers. The governance structure should be formalized and address the corporate and tax status of the Sub-Network Organization, its business plan and budget, intellectual property ownership and management, the entity’s statement of purpose and objectives, its decision making model, and its long-term strategic plan. Various types of governance model are acceptable.
2. Defining and meeting the particular information access needs of the region or sub-network while addressing the needs of patient populations that cross multiple communities nationwide or are contiguous but cross state lines.
3. Organizing the creation of “Articles of Federation” and other user agreements. A common set of multi-lateral policies, procedures, and standards to facilitate reliable, efficient sharing of health data among authorized users is required. The participating members of the health network must belong to and comply with agreements of a federation. Formal federation with clear agreements allows participants to access information that they have been authorized to share.
4. Supervising uniform adoption of information sharing policies or Articles of Federation by participating entities and mechanisms for their enforcement (e.g. sanctions).
5. Developing policies to address the need for retention and persistence of data.
6. Addressing conflicts among relevant stakeholders in a timely way.
7. Building, maintaining and managing the regional Record Locator Services and other sub-network systems and services.
8. Assuring that sub-network systems and the end-point systems of their members (including the Record Locator Service) adhere to the Common Framework.
9. Providing support to participants in the federation.
10. Establishing the financial sustainability models for the entity— responsibilities include:
11. Working with community payers, purchasers and providers to discuss participation, incentives and appropriate funding models.
12. Monitoring relevant stakeholder participation regarding conformance with the Common Framework and adoption incentives.
13. Ensuring that all of the information capabilities that define the Health Information Environment (including public health reporting and surveillance, research and improving health care quality) can be met over time.

• This approach should catalyze a market by creating a level playing field for market competition. Nevertheless, widespread clinical adoption will still depend on investment in the key components of the Health Information Environment and the re-alignment of incentives to reward and enable appropriate information use in clinical care.
• Incentives can include a wide variety of options from fundamental payment reform to eligibility for Federal assistance, eligibility to participate in federal demonstration projects, private-sector pay for performance incentives that require interoperability specified by the Common Framework, and eligibility to receive private IT adoption assistance.

Question 18. What roles and relationships should the federal government take in relation to how interoperability standards and policies are developed, and what roles and relationships should it refrain from taking?

• The federal government must play a central role in the Health Information Environment for it to succeed. That role includes:
• Taking a leadership role in creating incentives that are predicated on improving quality of care through IT
• Investing (with the private sector) in the creation of the SPE and providing seed funding to define and disseminate the Common Framework and the profiles for interoperability
• Medicare and Medicaid should coordinate their incentive structures, and should make sure they are compatible with incentives available to regional stakeholders.

Financial and/or Regulatory Incentives and Legal Considerations

Question 19. Are financial incentives required to drive the development of a marketplace for interoperable health information, so that relevant private industry companies will participate in the development of a broadly available, open and interoperable NHIN? If so, what types of incentives could gain the maximum benefit for the least investment? What restrictions or limitation should these incentives carry to ensure that the public interest is advanced?

• Yes, financial incentives are necessary for the Health Information Environment to be used as stated numerous times previously in this response.
• It would be unwise to establish a permanent payment system tied to IT adoption only; incentives for adoption should be time-limited to encourage rapid acquisition of “Common-Framework-enabled” applications that can connect and share data. Thereafter, funding should be incorporated within other payment methods.
• Maximum benefit for least investment would result from redesigning current fee-for-service reimbursement to include significant proportion of payment tied to validated health outcomes or evidence-based process measures.

Question 20. What kind of incentives should be available to regional stakeholders (e.g. health care providers, physicians, employers that purchase health insurance, payers) to use a health information exchange architecture based on a NHIN?

There are a variety of examples that merit further exploration:

• Pay for Performance incentives for improved outcomes based on validated measures and achieved as a result of health information access (e.g., avoidance of drug interaction by using the Health Information Environment for data access).
• Fund rapid experimentation with various models of reimbursement.
• Medicare and Medicaid should coordinate their incentive structures, and should make sure they are compatible with incentives available to regional stakeholders.
• Provide access to capital through low cost or government-backed revolving loans for EHR purchase.
• Develop a joint regional or national pool of funds to invest in clinical technology adoption by healthcare providers.
• Establish a matching grant program.
• Consider creative structuring to allow early transition from adoption-based to performance-based incentives, e.g., forgiving payments based on physicians meeting performance targets.
• Allow investment in EHR as a tax credit.
• (See “Financial, Legal and Organizational Approaches to Achieving Electronic Connectivity in Healthcare” at http://www.connectingforhealth.org/assets/reports/flo_sustain_healtcare_rpt.pdf for greater elaboration.)

Question 21. Are there statutory or regulatory requirements or prohibitions that might be perceived as barriers to the formation and operation of a NHIN, or to support it with critical functions?

• Legal safe harbors with restrictions
• Potential barriers that may be the result of inconsistency of state laws for healthcare information exchange need to be assessed.
• Healthcare payment policies and regulations that call for the inconsistent reporting of data or manipulation of codes representing healthcare data.
• Medical malpractice laws that may discourage physicians’ participation because of liability fears

Question 22. How could proposed organizational mechanisms or approaches address statutory and regulatory requirements (e.g. data privacy and security, antitrust constraints and tax issues)?

• The model proposed here would address issues regarding privacy and security, utilization of existing statutes such as HIPAA, use and access to information, business rules, and utilization of standards established in other domains to protect personal information.

Other

About the Health Information Environment

The Health Information Environment develops through the creation and connection of sub-networks that conform to the Common Framework of standards and policies.

• The quickest way to expand the Health Information Environment is by encouraging the parallel creation and connection of multiple sub-networks which all conform to the Common Framework.
• The Common Framework consists of the essential technical and policy requirements to enable the interoperation of standard interfaces and transactions at the local, regional and national level.
• Utilizing the Common Framework ensures economy of scale and speed of deployment and is essential because it enables the appropriate and necessary participation of national and super-regional entities (e.g., CMS, Kaiser, VA, etc.).

The Health Information Environment develops incrementally

• The Health Information Environment and the Common Framework that supports it should evolve over time and be responsive to new developments and ongoing innovation in technology and policy.

Healthcare applications are end-point systems connected to a “thin” Health Information Environment

• End-point systems include but are not limited to electronic health records, public health reporting systems, and other reporting systems.
• The Health Information Environment should facilitate the exchange of patient health information between end-point systems, or proxies for them, to improve the delivery of patient care and to further other health-related goals.
• The vendors or the operators of end-point systems support clinicians at varying levels of technology adoption (including those who do not yet have their own end-point systems) through “light” tools that offer clinicians Web-based information retrieval asymmetrically.
• A “thin” Health Information Environment builds upon the existing decentralized model and uses available Internet technologies.
• By utilizing existing Internet technologies, a “thin” Health Information Environment fosters increased competition and innovation by allowing industry efforts to focus on providing evolving healthcare-specific solutions.

Key to the Diagram

The Health Information Environment is a circular system; there is no “start” or “end” point because numerous transactions occur throughout it simultaneously. The following descriptions are of the elements portrayed in the diagram and the transactions associated with each of them. It is important to note that the diagram depicts one sub-network – many sub-networks of this type would be linked in an analogous fashion to comprise the full Health Information Environment. It is also important to highlight that all of the activities described by the diagram (excluding those of the end-point systems or applications) take place according to the guidelines set by the 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.

Common Framework

• The Common Framework specifies secure Internet based communication methods.
• Participants in the Health Information Environment are authenticated in a common fashion so that secure communications can occur.
• The Common Framework specifies information standards to allow unambiguous communication of clinical data.

Individual Care Providers

• Individual Care Providers, depicted by a circle on the left of the diagram, are the systems used by individuals or organizations to deliver or track care or health care operations.
• An Individual Care Provider system initiates an interaction with the Health Information Environment. For example, an authorized care professional might ask the Patient Index (also referred to as the Record Locator Service) whether there are any authorized records available that are necessary for the care of a patient (see the left side of the arc at the top of the diagram).
• An Individual Care Provider would use an end-point system or application – such as an electronic health record or providers’ portal via a thin web based client – as an interface to the Health Information Environment.

Patient Index (Record Locator Service)

• The Patient Index, also referred to as 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.
• The Patient Index (Record Locator Service), is at the top of the diagram. It contains a directory through which information about how to find the sources of authorized records can be found, not any of the actual content of the health records. The registry system knows where authorized records are, not what is in them.
• When an authorized Individual Care Provider submits a request to the Patient Index (Record Locator Service), it responds with information about the location (Data Sources or Information Sources) of any authorized and pertinent records (e.g. records for Jane Doe can be found at Hospital A and Lab B).

Message Transfer (Information Transfer)

• Message Transfer, (also described as Information Transfer), at the center of the diagram, is not an object, person, or institution, but an action—it represents what happens when one authorized part of the Health Information Environment shares authorized information with another.
• The standards and policies associated with the Common Framework include support for Message Transfer (Information Transfer).
• Message Transfer (Information Transfer) is initiated by a request from an Individual Care Provider directly to a Data Source (Information Source). The request could be made through a phone call, by paper, or electronically. The authorized information could be shared by fax, via a secure and standardized network connection using information standards defined by the Common Framework, or via paper.
• Requesting a Message Transfer (Information Transfer) of an actual record from a Data Source (Information Source) is an action distinct from requesting information from the Patient Index (Record Locator Service) about where records are located.
• When a provider retrieves data from another source to support a clinical decision the retrieved copy will usually become a part of the record maintained by the receiver.
• Message Transfer (Information Transfer) can also support anticipatory transfer of authorized patient information, including but not limited to distribution of lab results, referral reports, etc.

Data Sources (Information Sources)

• Data Sources, (also referred to as Information Sources), are the people or institutions that store health records. They are end-point systems supporting patients, providers, hospitals, diagnostic services, payers, or public health providers.
• When Data Sources (Information Sources) receive authorized requests for information from authorized Individual Care Providers, they send the appropriate records (a process described as Message Transfer or Information Transfer) – much as is done today.
• Data Sources (Information Sources) use end point systems or applications – such as electronic health records – as an interface to the Health Information Environment.
Data Sources (Information Sources) communicate regularly with the Patient Index (Record Locator Service) to make sure it is up to date about the availability of patient data, ideally registering this availability in “real time.”
• Data Sources (Information Sources) may also communicate with the Reporting Router as appropriate.

Reporting Router

• Reporting Router, at the bottom of the diagram, is an optional piece of infrastructure – a particular sub-network may choose whether or not to have one.
• The function of the Reporting Router is to find authorized identified or de-identified data appropriate for uses such as public health, quality improvement or research, and send or “push” it to the appropriate recipient (e.g. a public health agency, policy making body, research organization, etc).

Public Health

• Public Health, at the bottom left of the diagram, is an example of an entity, other than an Individual Care Provider, that may need access to health information.
• Public Health, like other users of the system, would access authorized information from the Health Information Environment via an end point system or application.

Example of How the Health Information Environment Works: Priscilla Switches Doctors

Above is an illustration of how linking, identification and transfer of a patient's records might happen. A patient, Priscilla Williams, moves and wants her new primary care physician at Clinic B, to have the results of her most recent pap smear, currently held at Clinic A. If her new physician can't get the results, she will have to take the test again, resulting in additional expense, difficulty, and delay.

Clinic A, a participant in the system, has provided the Record Locator Service with an authorized, updated list of patients it holds records on. This is a background process, where Clinic A communicates directly with the Record Locator Service at regular intervals, rather than part of the individual search transaction.

Once the staff of Clinic B has taken Priscilla’s identifying details (Transaction #1 above), they will authenticate themselves to the Record Locator Service (RLS) or to a local institution to allow for auditing. After they are authenticated, they will make a request for the location of any of Priscilla’s other authorized records.

The request from Clinic B to the RLS will travel over secure transport such as a Secure Socket Layers (SSL). On receiving it, the RLS will compare Pricilla’s information with their database. There are three possible outcomes here --the Record Locator Service finds records with such a high probability match that they can be identified as Priscilla's; it finds no records that match; or it finds records that might match, and asks Clinic B for more identifying information. (This third option would require staff allocated to handling such requests; some system designs may simply treat such ambiguous pairs as non-matches, to minimize human input, even at the expense of additional false negatives.)

Assuming there is a match, the RLS will return authorized pointers to other institutions such as Clinic A that hold her records (transaction #2 above). Clinic B will then make a request for Priscilla’s records directly to Clinic A, also via a secure internet connection, again providing authorization credentials to show that it is allowed to do so (transaction #3).

Some of the resulting authorized records may be returned from A to B directly over the Internet, using standardized interfaces for secure transport. The content of the messages may also be represented in a standardized format, for direct and automatic import into the new clinic’s database, while other records may be sent by secure email, or even simple fax. Once B has the results of her earlier pap smear (as well as any other records held by clinic A), the staff of Clinic B can then add them to Priscilla's file.

Question 24. How could success be measured in achieving an interoperable health information infrastructure for the public sector, private sector and health care community or region?

A comprehensive set of metrics should be established and tracked. Examples include:

• Ratio of users to potential users of the Health Information Environment
• Development and tracking of Healthcare Quality Indicators that derive from data access capability
• Speed with which outbreaks affecting the public’s health are identified
• Stable and secure coordination of key Health Information Environment functions
• Degree of interoperability across regional or other sub-networks
• Accountability to affected stakeholders, including effective independent review procedures
• Transparency, including procedural and financial transparency
• Financial metrics to evaluate the return on investment for each stakeholder.
• Representation of key interest groups, including the public interest representation
• Extent to which views of patients are taken into account in crafting policies and procedures relating to their rights and privacy
• Increased security of the root server system
• Support for long-term Internet and ICT evolution and innovation.
• Satisfaction of consumers with their health care system encounters
• Extent to which research and innovative approaches to prevention and treatment, (such as genetic treatment), are strengthened and made more cost-effective.
• Speed with which research results are integrated into health care and health-related decision-making.

APPENDIX A: Glossary of Key Terms

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 subnetworks 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.

APPENDIX B: Priority Areas for Continuing Work

Commercialization – While the development of some commercial applications that are integrated into the Health Information Environment is desirable and should be encouraged, it is important to differentiate and constrain those commercial uses that may hamper the ability of providers and patients to gain maximum benefit from access to clinical information, or compromise their trust. The Health Information Environment should not be used as a method to selectively steer commercial interests to the point of care in an unrestricted way or in a way that alters the neutrality of the infrastructure. Which types of commercial activity based on the Health Information Environment should be discouraged? Who should decide and how should this decision be enforced?

Finance – What is the best financial model to support the development and maintenance of the Health Information Environment? How should public and private funds be allocated? How should incentives for use of the environment be structured? What is the best model to support traditionally underserved communities?

Patient Control/Education – What are the implications of patient control of health information? What are the best ways to educate the public about how to use health information and ensure that patient consent to information exchange is meaningful? How should the public understand or engage with the Record Locator Service? What process and / or entities should carry out patient education, and how can multiple efforts best be coordinated?

Reconciliation of Potentially Conflicting State Laws – How do some state laws impede our ability to achieve vital national objectives? How should differences in state laws regarding access to or use of health information be addressed? What are the sources of leadership for reconciling state and federal legislation?

Standards and Policy Entity – The SPE may be an existing organization or a new organization modeled after other quasi-governmental or public-private organizations. Immediate, near-term efforts need to include an analysis of both the public and private sectors for viable models. These efforts should be completed in no more than one year. The analysis of organizational models could be conducted by the Institute of Medicine (IOM), an agency of the NRC such as the CSTB, a new specially appointed Commission/Task Force, or other existing entity with the appropriate stature and credibility.

Validation of Conformance and Interoperability – What processes should be used for validating compliance with the Common Framework? Should the mechanism be persistent? How should compliance be enforced?

• 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.
• Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
• The technical standards address secure transport over the Internet and other networks, and provide the essential required components for the infrastructure including secure connectivity, reliable authentication and a suite of defined interchange formats for health care data.
• The policy standards address the privacy, security and use and access policies for the exchange of health information.
• The Common Framework also provides a uniform methodology for the identification of users.
• The modular character of the Common Framework permits rapid attainment of an interoperable information environment using essential requirements but also scales to a more complete structured data interchange for enhanced performance. The suite of interoperability standards will be enhanced over time.
• The Common Framework is the basis of all subsequent use cases that require specific, uniform interoperable standards to support information exchange. Use cases and accompanying information standards will be specified for each of the myriad of health information exchange requirements and will be supported by detailed implementation guides.
• The participants in sub-networks will determine which profiles are appropriate to address the requirements established by their stakeholders.
• The Common Framework, and mechanisms to enforce compliance with it, ensures the creation, interoperability, scalability, efficiency and ongoing evolution of this environment.
• This work will necessarily involve choices that eliminate some of the variability in the standards while attaining interoperability.
• The Common Framework enables a set of open, non-proprietary interfaces and information transfer protocols to be developed to achieve interoperability. This also permits less standardized records to be accessed reliably and rapidly; it facilitates the best possible interoperability among end-points systems of differing levels of sophistication.
• The Common Framework relies upon standards for data content and transmission developed by nationally accredited organizations using an open and consensus-based process. It builds upon existing standards development activity and HIPAA.
• The Common Framework should be required across all health communities, including the clinical research community, public health, etc.

• The Common Framework, and mechanisms to enforce compliance with it or other applicable standards and policies will be an essential condition of the development of the Health Information Environment. The Common Framework ensures the creation, interoperability, scalability, efficiency and ongoing evolution of this environment. Mechanisms to test and validate compliance may be necessary in several domains, including the “highest” or network environment level, the sub-network level, and the level of end point applications (e.g., EHRs). Validation methodologies should be appropriate to the information exchange, requiring only the elements and protocols essential to participation in the Health Information Environment, in a way that encourages innovation and new entrants to the market.
• An external mechanism for validating compliance with the standards of the Common Framework is required for the early phases, but the network may eventually become entirely self-validating. There is uncertainty about how long the outside compliance validation mechanism may be necessary—until the point at which there is a significant level of stability in the Health Information Environment. From the beginning, self-assessment should be built into the compliance validation mechanism because it helps to assure that programs are on track on a continuous basis, rather than waiting for an outside party to identify significant problems.
• Interface and transaction interoperability standards should allow for the appropriate and authorized integration of financial transaction information with related clinical transactional data.
• The Health Information Environment is inclusive of participants of varying levels of technical and functional sophistication. Its standards, rules and vocabularies can accommodate a wide variety of participants at any one time and can also be revised over time as user requirements evolve.

On the specific issue of market incentives and business objectives

• Healthcare suffers from a fragmented and stalled market for IT—both for connectivity and IT adoption generally.
• There is no “network effect” today in healthcare IT.
• The promulgation of a Common Framework will immediately accelerate the value of adopting IT by creating confidence in the ability of IT systems to reliably enable connectivity. Agreement on conformance validation mechanisms for interoperability will enhance this effect.
• This approach should catalyze a market by creating a level playing field for market competition. Nevertheless, widespread adoption of interoperable clinical IT will still depend on investment in the key components of the Health Information Environment and the use of incentives that recognize appropriate information use in clinical care.
• Incentives can include a wide variety of options from fundamental payment reform to eligibility for Federal assistance, eligibility to participate in federal demonstration projects, private-sector pay for performance incentives that require interoperability specified by the Common Framework, and eligibility to receive private IT adoption assistance.
• Incentives that reward the improved decision-making and quality of care enabled by the Health Information Environment will be more effective at driving participation than incentives tied specifically to IT adoption or network participation.

Question 3. What aspects of a NHIN could be national in scope vs. local or regional? Please describe the roles of entities at those levels.

• The Health Information Environment will take shape incrementally, over time. Its development will include both “top-down” (i.e., nationally-defined) policies and standards, and “bottom-up” (i.e., community and market-driven) initiatives.
• Both local and national strategies are needed. Most healthcare is local, and a great deal of information access occurs in a patient’s own community. At the same time, many patients receive care, coverage, and benefits across multiple regions; also, the US population is highly mobile, whether moving across state lines from home to work or from winter to summer homes. Many multi-institution networks, that effectively comprise local health information infrastructures, already exist and must be accommodated.
• In general our proposed model for the Health Information Environment is decentralized and regionally driven. It is desirable to leave to the local systems those things best handled locally, while specifying at a national level those things required as universal in order to allow for interoperability among regional systems. The Common Framework, comprised of the essential security and interoperability standards required to assure secure Internet transmission or patient matching methods, must be national, so that all participating institutions can connect to one another securely and without unworkable variation.

The various regional and national roles and entities for the Health Information Environment are:

• Each region or sub-network needs an entity (Sub-network Organization) to oversee its health information environment. Regional sub-networks have a public interest responsibility to address the needs of the entire population and all health information providers. Some sub-networks will be geographically based and others will be functional or organizational, crossing geographical boundaries. Some of these enterprise or private sub-networks (e.g., a large health system or research network) may not be subject to the same public interest governance and policy obligations. The responsibilities of the Sub-Network Organizations include:
1. Establishing a multi-stakeholder governance structure that includes the representation of patients and consumers and safety net providers. The governance structure should be formalized and address the corporate and tax status of the Sub-Network Organization, its business plan and budget, intellectual property ownership and management, the entity’s statement of purpose and objectives, its decision making model, and its long-term strategic plan. Various types of governance model are acceptable.
2. Defining and meeting the particular information access needs of the region or sub-network while addressing the needs of patient populations that cross multiple communities nationwide or are contiguous but cross state lines.
3. Organizing the creation of “Articles of Federation” and other user agreements. A common set of multi-lateral policies, procedures, and standards to facilitate reliable, efficient sharing of health data among authorized users is required. The participating members of the health network must belong to and comply with agreements of a federation. Formal federation with clear agreements allows participants to access information that they have been authorized to share.
4. Supervising uniform adoption of information sharing policies or Articles of Federation by participating entities and mechanisms for their enforcement (e.g. sanctions).
5. Developing policies to address the need for retention and persistence of data.
6. Addressing conflicts among relevant stakeholders in a timely way.
7. Building, maintaining and managing the regional Record Locator Services and other sub-network systems and services.
8. Assuring that sub-network systems and the end-point systems of their members (including the Record Locator Service) adhere to the Common Framework.
9. Providing support to participants in the federation.
10. Establishing the financial sustainability models for the entity— responsibilities include:
1. Working with community payers, purchasers and providers to discuss participation, incentives and appropriate funding models.
2. Monitoring relevant stakeholder participation regarding conformance with the Common Framework and adoption incentives.
11. Ensuring that all of the information capabilities that define the Health Information Environment (including public health reporting and surveillance, research and improving health care quality) can be met over time.
• In regions where there is low potential for an organizing function, (e.g., rural and underserved), other models of non-geographic sub-networks and Sub-Network Organizations should be established to support these necessary subnetworks. For example, there may be cases, especially in rural areas, where specialized clinical data repositories, or proxies, are shared by the providers in the community. Rural networks that may be meeting the needs of relatively closed provider networks may be best served by shared clinical data repositories that allow acceptable access speeds even when broadband Internet access is limited or less efficient. Any model must include the possibility for such clinical data repositories or proxies to exist as long as they comply with the Common Framework for interacting with other sub-networks as appropriate for patient care or other authorized use. Alternatively, some Sub-Network Organizations can explore potential partnerships with the appropriate State Health Departments, Medial Societies, NGOs, etc.

National

• A Standards and Policy Entity (SPE) to identify and recommend standards and policies for the “Common Framework”-a set of essential technical and policy requirements that enable the interoperation of standard interfaces and transactions at the local, regional and national level (more fully described in the next question).
• Privacy guidelines and policy clarification re: HIPAA, anti-kickback, potentially conflicting state laws and anti-trust laws.
• Performance and accountability metrics
• Experimentation with and creation of financial incentives that require the Common Framework
• Special attention, funding and mechanisms of support for rural and underserved communities
• Enforcement policies for misuse of data
• Coordinated efforts to ensure public understanding of the benefits of health information exchange and patients’ rights in the information exchange environment.

Organizational and Business Framework

Question 4. What type of framework could be needed to develop, set policies and standards for, operate, and adopt a NHIN? Describe the kinds of entities and stakeholders that could compose the framework and address the following components:

1. How could a NHIN be developed? What could be key considerations in constructing a NHIN? What could be a feasible model for accomplishing its construction?
2. How could policies and standards be set for the development, use and operation of a NHIN?
3. How could the adoption and use of the NHIN be accelerated for the mainstream delivery of care?
4. How could the NHIN be operated? What are key considerations in operating a NHIN?

• An over-arching principle in the development and operation of the Health Information Environment is the importance of serving the public interest: it must above all meet the needs of patients by enabling the provision of high quality care at reasonable costs.
• Consumer and patient advocates, amongst all other stakeholders, must be represented on an equal footing in the governance and advisory structure of all regional and national Health Information Environment authorities, including standard-selection and operational entities. Beyond this requirement, various governance models should be explored to balance stakeholder input while not becoming unduly burdensome.
• The Health Information Environment, like the Internet that functions as its core, will not be operated by a central entity. However, like the Internet, which has centralized functions such as domain name assignment, the Health Information Environment will require the centralization of some functions, such as those to be carried out by the Standards and Policy Entity described below.

The Five Critical Key Components of the Health Information Environment are:

1. The establishment of the Standards and Policy Entity (SPE):
   1. The SPE is a public-private collaborative entity that identifies and specifies the detailed implementation rules, including business rules, for the standards and policies that make up the Common Framework. It identifies and recommends the technical standards and information policies essential for establishing privacy, security and interoperability. The SPE is responsible for the identification, specification, interpretation, and dissemination of these standards and policies.
   2. Given the unusually sensitive nature of health information and the complexity of the technical standards and policies needed to guide its use, it is imperative that a single entity – the SPE – be responsible for decisions related to both domains so that they can be closely integrated. While the SPE must be the authority regarding matters in both domains, it may delegate pieces of its work requiring particular expertise to other entities. The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE.
   3. Without this, every entity that has to interact with the network will be unable to do so reliably and consistently—multiple and differing approaches to core aspects at the regional level would create undue burden on patients and providers that cross sub-networks, public and private payers, large delivery organizations, labs, PBMs, pharmacy chains, vendors who supply applications, etc.
   4. The SPE must not be disproportionately dependent on any of its stakeholders for its funding and must operate independently.
   5. The SPE requires public and private support.
   6. The SPE’s governance and administration must be transparent, accountable, and reflect the participation of all stakeholders, including representatives of the general public who are able to participate on an equal footing. The SPE administration includes a mechanism or formal process that reflects the participation of sub-networks and regional organizations.
   7. The SPE must protect the public good and ensure that consideration be given to enforcement functions.
   8. The SPE must be established and funded as soon as possible in order to continue the work of defining the Common Framework under which all the sub-networks will operate. Once the initial set of policies and standards are in place, and with proper incentives, the Health Information Environment will begin to grow and evolve organically and continually.
   9. The SPE must strive for maximum cost-effectiveness by building on existing standards and policy work (no “rip and replace”), establishing legitimate yet efficient processes and minimizing the negative economic impact of any new requirements it defines. As a general principle, the SPE should seek existing solutions and minimal modifications, creating new solutions only as a last resort. Even so, some change will be required to ensure interoperability across the boundaries of existing standards. The extent of such change must be determined using a defined process. To do so effectively requires close and continuous interaction with standards development organizations (SDOs) and other potential sources of relevant models for its own work.
   10. The requirements for interoperability will be specified in a suite of profiles or use cases defined and detailed by the SPE and premised on the Common Framework. The use cases will be specified via the selection of candidate suites or profiles of standards, for which detailed implementation and technical guides will be made available. The SPE must balance what is practical to implement with the needs of the nation.
   11. The SPE may be an existing organization or a new organization modeled after other quasi-governmental or public-private organizations. Immediate, near-term efforts need to include an analysis of both the public and private sectors for viable models. These efforts should be completed in no more than one year. The analysis of organizational models could be conducted by the Institute of Medicine (IOM), an agency of the NRC such as the CSTB, a new specially appointed Commission/Task Force, or other existing entity with the appropriate stature and credibility.
   12. The SPE must vigilantly guard against an accretion of duty or scope over time: its mission must always be to define and maintain the minimum framework necessary for the successful operation of the Health Information Environment.
2. The creation of multi-stakeholder, collaborative, public interest Sub-Network Organizations at the regional or the non-geographic “sub-network level” that facilitate the development, implementation, and application of secure health information access by establishing and overseeing the sub-networks’ governance and operation (including the Record Locator Service).
3. Financial and non-financial incentives to increase HIT adoption by clinicians and other information suppliers and users and to encourage their connectivity consistent with the Common Framework. These incentives may include loans, grant funding and private and public investment through reimbursement changes. Three tiers of funding and incentives need to be in place to build the Health Information Environment:
1. Providing support for ongoing investment in the Common Framework and the standards and policies created and maintained by the SPE
2. Providing sufficient funding to seed the creation of self-sustaining regional initiatives consistent with the Common Framework
3. Accelerating the adoption of electronic health record systems that adhere to the Common Framework, and that promote high quality healthcare based on greater access to health information.
4. A mechanism for validating compliance with the SPE Common Framework and standards. Early in the evolution, a separate private sector mechanism that may or may not be distinct from the SPE, is needed for validating compliance with the SPE Common Framework and standards and policies. Ultimately the network effect may create a mechanism for self-enforcing compliance. The method for validation must encourage, not deter, new entrants to the health IT market for tools and services to encourage competition and innovative business models.
5. Special attention must be given to underserved communities to ensure that they receive additional support and that they are mandatory, early participants in regional initiatives and sub-networks. In regions where there is low potential for an organizing function, (e.g., rural and underserved), other models of non-geographic sub-networks and Sub-Network Organizations should be established to support these necessary subnetworks. State Health Departments, medical societies, or other non-government organizations may be able to assist in these communities. As with other health policy issues that affect underserved populations, government funding may be necessary to support this goal. See further elaboration earlier in this draft.

Question 5. What kind of financial model could be required to build a NHIN? Please describe potential sources of initial funding, relative levels of contribution among sources and the implications of various funding models.

• We have prepared a single response to questions 5 and 6 because there is great overlap in the financial model to build the Health Information Environment and to operate and sustain it. There are, indeed, requirements in the early years that must precede other activities that could be considered a “build” period and these will be identified below. However, many of these same activities must persist throughout the lifetime of the Health Information Environment. Furthermore, “building” the Health Information Environment will continue indefinitely and the distinction between “building” and “operating and sustaining” the Health Information Environment will blur.

The Health Information Environment is premised on creation of value:

• The Health Information Environment development approach must create value for all of the stakeholders it connects, including (but not limited to) payers, providers, and consumers. It must build and sustain a robust marketplace for investment and continuous development of the infrastructure.
• The Health Information Environment creates value, and does not incur net, long-term costs for the federal government or other stakeholders.
• The Health Information Environment will create value by returning greater financial savings to U.S. society through use of HIT than the costs incurred through adoption of EHRs, the sub-networks of which they are part, and the support of the environment in which they operate. (See “Accelerating US EHR Adoption: How to Get There From Here, Recommendations Based on the 2004 ACMI Retreat” by Blackford Middleton, W. Ed Hammond, Patricia F. Brennan, and Gregory F. Cooper,, J Am Med Inform Assoc. 2005; 12: 1319.)
• Full systematic interoperability has been estimated to save $78 billion per year in the United States compared with current manual methods of data recording, re-recording and transport. (See "The Value of Health Care Information Exchange and Interoperability" by Jan Walker, Eric Pan, Doug Johnston, Julia-Adler Milstein, David Bates, and Blackford Middleton at CITL. Health Affairs Web Exclusive, January 19, 2005.)

Financial Requirements for the Health Information Environment to be created and maintained:

• The Health Information Environment cannot and should not be built and funded independently of creating incentives for its use. If it is financed without corresponding changes to re-align incentives for its use, providers will remain unlikely to use the sub-networks to support patient care, crippling its success.
• The financial model must result from a combination of sustained public sector investment of core functions, seed funding for novel components and must also result from significant and sustained commitments of private capital.
• The early phase of the Health Information Environment, which could be considered the “build” phase, should include financing for the following activities:
1. The creation of the SPE and the initial development of the Common Framework
2. Seed funding of a critical mass of sub-networks that conform to the Common Framework
3. Financial incentives to providers to adopt HIT that conforms to the Common Framework and to participate in the sub-networks.

Each of the components of the “build phase” is elaborated below:

1. Funding the SPE:
• The SPE must be established and funded as soon as possible in order to continue the work of defining the Common Framework according to which all the sub-networks will operate. Once the initial set of standards and policies are in place, the Health Information Environment will grow and evolve organically and continually.
• The SPE will operate indefinitely and continually refine and evolve the policies and standards and therefore must also be funded as part of the continuing operation of the Health Information Environment.
• The SPE must have a secure funding source and be subject to public sector oversight to insure continuity of governance of the Health Information Environment. Core funding may be provided by DHHS but private sector contributions should provide a significant proportion of total support over time.
• The SPE may be an existing organization or a new organization modeled after other quasi-governmental or public-private organizations. Immediate, near-term efforts need to include an analysis of both the public and private sectors for viable models. These efforts should be completed in no more than one year. The analysis of organizational models could be conducted by the Institute of Medicine (IOM), an agency of the NRC such as the CSTB, a new specially appointed Commission/Task Force, or other existing entity with the appropriate stature and credibility.
2. Seed Funding of the Sub-networks:
   • As a general principle, the sub-networks must be self-funded and self-sustaining.
   • In order to “prime the pump”, accelerate early growth, and demonstrate early success of the Health Information Environment, government grants should be provided as seed funding to a selected group of sub-networks. This has already begun with the initial AHRQ grants.
   • Given the intended national scope of the regional sub-networks, significantly more capital will be needed for start-up grants than has recently been made available.
   • Recipients of such start-up grants must agree to use the Common Framework and to create requirements for participants within their network to do so. They must, in addition, adopt policies that reflect the public interest including equitable access, participation in governance and policy making, consumer and professional outreach, and transparency.
   • A financing model will need to be developed to provide startup and operations support for traditionally underserved communities of interest like those described in question 11.
   • To assist with seed-funding of the sub-networks, a range of capital financing vehicles could be employed, including grant funding, long-term revolving loan funds and tax credits to investors. Such funds could come from a wide range of sources, including various public and private sector funds and vehicles. Government participation in the seeding of these activities is critical and will accelerate private sector investment. In addition to direct funding, the Government’s provision of guarantees of bond issuances or loans can also facilitate private sector investment.
   • All healthcare stakeholders that benefit from the sub-network should work together to assure sustainability and appropriate funding. Costs that could be covered by the model might include those related to the Record Locator Service, community governance, and other community-based operational HIT components.

3. Financial Incentives for adoption of interoperable HIT:
• Financial incentives to providers for the adoption of HIT that conforms to the Common Framework will be among the factors leading to a critical mass of participants in the early phase of the Health Information Environment.
• Community consortia of public and private payers and purchasers, working in partnership with CMS and other major payers, should share ideas and early findings regarding effective incentive models. Such incentives may reward those clinicians who successfully adopt and use HIT to improve quality performance, and actively participate in the appropriate sub-networks.
• Incentive arrangements for HIT adoption must recognize that a critical mass of funding must be available to reduce "free ride" potential in which some organizations forgo participation yet reap the benefits.
• To further reduce “free ride” potential, it will be the responsibility of the Sub-Network Organizations to:
  • Work with community payers, purchasers and providers to discuss participation, incentives and appropriate funding models.
  • Monitor relevant stakeholder participation regarding conformance with the Common Framework and adoption incentives.

Question 6. What kind of financial model could be required to operate and sustain a functioning NHIN? Please describe the implications of various financing models.

Question 7. What privacy and security considerations, including compliance with relevant rules of HIPAA, are implicated by the NHIN, and how could they be addressed?

• All of the capabilities of the Health Information Environment including the delivery of care, the conduct of research, and public health reporting, must be conducted in an environment of trust, consistent with appropriate requirements for patient privacy, security, confidentiality, integrity, audit and informed consent.
• Participation in the Health Information Environment by providers, patients, or others must be voluntary; no one must be required to share information.
• The Health Information Environment is premised on a model of patient authorization and control. Patients must be able to: choose whether or not to participate in sharing personally identifiable information; exercise their rights under HIPAA; control who has access to their records (whether in whole or in part); see who has accessed their information; review, contribute to and amend their records (without unreasonable fees); receive paper or electronic copies of their information; and reliably and securely share all or portions of their records among institutions. Once patient consent has been granted for a certain type of information access, however, information should be able to be accessed freely in a trusted environment.
• Clinical data will be managed by those who have a direct relationship with the patient (patients may also keep their own records of their own information).
• No mandated national unique health ID is required, but standardized methodologies to identify patients are required.
• No single repository is intended to hold all of a patient’s clinical data (although this does not preclude patients from aggregating their data, either on their own or through the services of a trusted third party such as a personal health record or PHR provider).
• Authorization and authentication of users takes place at the regional, sub-network or local institution level.
• Sub-networks will be required to participate in some form of validation process.
• The Health Information Environment is a network of networks, linked only by registries through which authorized information about how to find the locations of records can be found, not any of the actual content of the health records. Thereby, the registry system knows only where records are, not what is in them.
• To achieve these capabilities, the Health Information Environment requires the addition of one new piece of infrastructure at the sub-network level based on an architecture that separates the function of locating authorized records from the function of transferring them to authorized users. This piece of infrastructure is the Record Locator Service (RLS) and is operated by a multi-stakeholder collaborative at the regional or non-geographic sub-network level and built on the current enterprise use of Master Patient Indices. The RLS itself is subject to privacy and security requirements, and is based on open standards set by the SPE.
• The system supports
  1. Linking of records via a registry of names and record location information, and sharing among users participating in the system, but it also allows
  2. Linking without sharing, or sharing pursuant only to higher authorization, as well as
  3. The ability to choose not to link information in certain sensitive treatment situations determined by users.
  By leaving these decisions at the edges (e.g., with patients and the professionals that support them), the architecture supports a range of approaches. It also allows higher levels of approval to be set locally for sharing some records. This obviates the need to have “one size fits all” policies as would be necessary for centrally controlled approaches. 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.
• The Privacy and Security Principles (as outlined by Connecting for Health’s Linking Workgroup) for the sub-networks and the broader Health Information Environment must address:
1. Confidentiality: Material existing within the system will only be disclosed to those authorized to have it.
2. Authentication: The system will require identification for use by all authorized individuals, thus both deflecting unauthorized use and enabling auditing for monitoring of compliance with policy guidelines.
3. Integrity: Material in the system will be defended against unauthorized alteration, and all alterations will be logged.
4. Non-repudiation: Transactions undertaken in the system will be acknowledged by both parties, and cannot be unilaterally revoked or altered.
• The Security Standards (as outlined by Connecting for Health’s Working Group on Accurately Linking Information for Health Care Quality and Safety in its report: Linking Healthcare Information: Proposed Methods for Improving Care and Protecting Privacy) must address:
1. Wire Security: Securing material “on the wire” means making sure that in its transit from point A to point B it is defended from eavesdropping, copying, or other interception. In practice, this can mean encrypting all the material passing over that connection, and ensuring that it is effectively delivered to the desired recipient.
2. Perimeter Security: Perimeter security involves requiring some form of authorization credentials for anyone using the system for any reason, as well as an auditing program that allows use of the system to be evaluated later.
3. Content Security: Sometimes a user is both authorized to use the system and a malefactor, as with the hypothetical examples of a file clerk searching for his girlfriend’s records, or the intern looking at the records of a famous patient. This type of attack can be limited by restricting what can be done with the data, even by authorized personnel, and by making sure that physical access to the equipment does not translate directly to access to its contents.

Question 8. How could the framework for a NHIN address public policy objectives for broad participation, responsiveness, open and non-proprietary interoperable infrastructure?

The Five Critical Key Components of the Health Information Environment, when taken together, will address public policy objectives for broad participation, responsiveness and the creation of a non-proprietary interoperable infrastructure. The Five Critical Components are:

1. The establishment of the Standards and Policy Entity (SPE) – (More fully described under Question 4). The SPE is a public-private collaborative entity that identifies and recommends the detailed implementation rules for the standards and policies that make up the Common Framework. The SPE’s policy recommendations for use, access, privacy and security of health information are essential for the success of the Health Information Environment. These policies inform users, policy makers and sub-network developers who implement the technical standards recommended by the SPE. The SPE operates and is funded without dependence on any one stakeholder group. It is transparent, accountable, and reflects the participation of all stakeholders, including the public. The SPE offers essential guidance – to encourage an innovative marketplace, regional control, and minimum redundancy or rework. While actively identifying and responding to new needs and the lessons of experience, the SPE is above all pragmatic, offering practical tools to address the most pressing priorities. <