Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services.
Request for information.
The nationwide health information network is defined as the set of standards, services, and policies that enable secure health information exchange over the Internet. Enacted in February 2009, the Health Information Technology for Economic and Clinical Health (HITECH) Act requires the
To be assured consideration, written or electronic comments must be received at one of the addresses provided below, no later than 5 p.m. on June 14, 2012.
You may submit comments identified by any of the following methods below (please do not submit duplicate comments). Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission.
•
•
•
Steven Posnack, Director, Federal Policy Division, Office of Policy and Planning, Office of the National Coordinator for Health Information Technology, 202–690–7151.
Electronic health information exchange (referred to as “electronic exchange” in the text that follows) addresses a critical need in our healthcare system and provides the foundation for improved care coordination and quality improvement. However, absent a common set of rules to guide its development and nationwide expansion, electronic exchange has been governed by a patchwork of contractual relationships, procurement requirements, State and Federal laws, and industry self-regulation through accreditation and certification. Consequently, this ad-hoc governance approach has led to asymmetries in the policies and technical standards, which are evident in the various local, regional and State electronic exchange activities. Because of the expected increase in demand for electronic exchange capacity to support innovative care and payment models now underway as well as proposed meaningful use Stage 2 objectives and measures, stakeholders have communicated to the Office of the National Coordinator for Health Information Technology (ONC) that a consistent, baseline set of “rules of the road” for electronic exchange is desirable, and perhaps necessary.
We believe that this is an opportune time to solicit input on how the governance mechanism for the nationwide health information network should be shaped and how we could effectively use our statutory authority to complement existing Federal regulations to support and enable nationwide electronic exchange. We also believe that a properly crafted governance mechanism could yield substantial public benefits, including: reduced burden and costs to engage in electronic exchange; added protections for consumers and health care providers; and, in the long-run, a more innovative, and efficient electronic exchange marketplace that would ultimately create an environment where electronic exchange is commonplace and “worry-free.”
For individual consumers, one of the governance mechanism's potential benefits could be the establishment of additional safeguards specific to electronic exchange that are not addressed by other Federal laws, such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rules, or State laws. For example, the governance mechanism could include more prescriptive and/or more stringent policies for entities that facilitate electronic exchange than are included in the HIPAA Privacy and Security Rules. From a health care provider's perspective, we anticipate that the governance mechanism could provide assurances to all electronic exchange parties that a specified set of requirements have been met. In turn, we believe these assurances could help spur greater trust and confidence in electronic exchange among providers and ease concerns associated with sharing patient information. Finally, for the entities that facilitate electronic exchange, we believe that the governance mechanism could enable a more competitive and open electronic exchange market and make it more efficient for these entities to exchange electronic health information.
This request for information (RFI) reflects ONC's current thinking regarding the approach ONC should take to establish a governance mechanism for the nationwide health information network. It frames many of the draft proposals and concepts ONC is considering, and depending on comments ONC receives, many of these concepts could be included in a future notice of proposed rulemaking. We seek public comment on whether it is timely for ONC to act to establish a governance mechanism; the advantages, disadvantages, and anticipated market impact of the potential proposals we discuss; and whether we should consider any alternatives in place of, or in combination with, the proposals discussed in this RFI.
Overall, we believe that it would be impracticable and imprudent to establish through regulation a “one-size fits all” approach to governance. Given the constantly evolving technical and policy landscape applicable to electronic exchange, it would be onerous and perhaps unachievable to specify up front all forms of electronic exchange to which the governance mechanism could apply. Rather, we view the nationwide health information network as a continually expanding ecosystem of electronic exchange activities for which stakeholders would be able to select the appropriate set of standards, services, and policies to meet their electronic exchange needs. This ecosystem would encompass many forms of electronic exchange, ranging from simple forms (such as when the electronic exchange of health information is planned and sent to a known destination) to more sophisticated forms (such as when the electronic exchange is unplanned meaning the data source is unknown beforehand and query and response techniques are utilized). It would also accommodate emerging exchange activities as they gain policy and technical maturity, such as the use cases being proven by the participants in the nationwide health information network Exchange initiative.
In rulemaking, we would seek to launch the structures, processes, and initial requirements that would be necessary for the governance mechanism to operate. In subsequent rulemakings, we anticipate addressing evolving electronic exchange requirements and the standards and policies necessary to effectively govern new and perhaps more complex forms of electronic exchange. Below, we briefly summarize the proposals this RFI covers and provide more detailed explanations for each proposal in the sections that follow.
•
•
•
•
•
We have intentionally presented many details of our considerations in this RFI. We hope that this level of detail will generate more specific and insightful comments and a more comprehensive dialogue. In establishing a governance mechanism, ONC is committed to obtaining ongoing public input, and we are consequently also relying heavily on the HIT Policy Committee
The Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (ARRA) (Pub. L. 111–5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and established “Title XXX—Health Information Technology and Quality” to improve health care quality, safety, and efficiency through the promotion of HIT and the electronic exchange of health information. More specifically, section 3001(c)(8) of the PHSA, requires the National Coordinator for Health Information Technology (National Coordinator) to “establish a governance mechanism for the nationwide health information network.” Thus we interpret section 3001(c)(8) of the PHSA with sufficient breadth to enable the National Coordinator to establish a mechanism for governing the nationwide health information network, which we define as the set of standards, services, and policies that enable secure health information exchange over the Internet.
We note that Congress in section 3001(b) of the PHSA directed the National Coordinator to perform his duties under section 3001(c) in a manner “consistent with the development of a nationwide health information technology infrastructure that allows for the electronic use and exchange of information” and that accomplishes the eleven outcomes specified in PHSA section 3001(b) for which the National Coordinator is responsible. Moreover, we believe the authority granted to the National Coordinator at section 3001(c)(1)(A) to “review and determine whether to endorse each standard, implementation specification, and certification criterion for the electronic exchange and use of health information that is recommended by the HIT Standards Committee under section 3003 for purposes of adoption [by the Secretary] under section 3004” as well as the National Coordinator's authority to consider policy recommendations from the HIT Policy Committee as described in section 3002(b) of the PHSA would support the approach we are considering to establish for the nationwide health information network governance mechanism.
Section 3002(b)(2)(A) of the PHSA authorizes the HIT Policy Committee to “recommend the areas in which standards, implementation specifications and certification criteria are needed for the electronic exchange and use of health information for purposes of adoption under section 3004 and [to] recommend an order of priority for the development, harmonization, and recognition of standards, specifications, and certification criteria * * *.” Section 3002(b)(3) states “[t]he HIT Policy Committee shall serve as a forum for broad stakeholder input with specific expertise in policies relating to the matters described in paragraphs (1) and (2).”
Section 3003(b)(1)(A) of the PHSA states that “[t]he HIT Standards Committee shall recommend to the National Coordinator standards, implementation specifications, and certification criteria described in subsection (a) that have been developed, harmonized, or recognized by the HIT Standards Committee * * *.” Section 3003(b)(2) directs the HIT Standards Committee to “serve as a forum for the participation of a broad range of stakeholders to provide input on the development, harmonization, and recognition of standards, implementation specifications, and certification criteria necessary for the development and adoption of a nationwide health information technology infrastructure that allows for the electronic use and exchange of health information.”
Lastly, section 3004 of the PHSA in turn identifies a process for the adoption of HIT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria.
The success of electronic exchange under the auspices of the nationwide health information network depends, in large part, on assurances that personally identifiable health information will remain confidential and secure. Existing Federal standards governing the privacy and security of health information establish an essential baseline of protection on which we anticipate building through nationwide health information network governance.
The Privacy and Security Rules issued under HIPAA established the first generally applicable Federal protections for health information maintained by certain key segments of the health care industry: health care providers who transmit health information electronically in connection with a transaction for which the Secretary has adopted a standard, health plans, and health care clearinghouses (collectively called “covered entities”). The HIPAA Privacy Rule sets the standards and implementation specifications for the use and disclosure of individually identifiable health information (IIHI) held by these covered entities (called protected health information or PHI). It is notable that the HIPAA Privacy Rule was not intended to establish best practices with which covered entities could voluntarily comply; rather, it establishes a baseline of enforceable Federal regulatory protections upon which the States or covered entities (as a matter of organizational policy) are free to expand.
The HIPAA Security Rule requires covered entities to establish specific administrative, physical, and technical safeguards
Subtitle D of the HITECH Act (sections 13400–13424) expanded the protections afforded by HIPAA by requiring, among other things, business associates (generally, persons or entities that create, receive, maintain, or transmit PHI on behalf of, or in the provision of certain services to, a covered entity) to comply with certain HIPAA Privacy Rule provisions and the standards and implementation specifications of the Security Rule.
Over the past decade the nationwide health information network has been conceptualized in several different ways. The following provides a brief history of the major activities, events, and milestones that have shaped our understanding and conceptualization of the nationwide health information network.
In 2001, the National Committee on Vital and Health Statistics (NCVHS) issued recommendations on nationwide electronic health information exchange within a report titled “Information for Health, A Strategy for Building the National Health Information Infrastructure.” In this report, NCVHS outlined three dimensions of health information infrastructure (Personal Health; Healthcare Provider; and Population Health) that would be important for “conceptualizing the capture, storage, communication, processing, and presentation of information.” NCVHS also recognized that ensuring the confidentiality and security of personal health information was paramount in developing the infrastructure to enable nationwide electronic health information exchange. Noting that the HIPAA Privacy Rule provided strong protections for individually identifiable health information, the NCVHS also forecasted that additional protections would be needed to extend across all the users, technologies, and functions envisioned by the nationwide health information network.
Since 2004, when the Office of the National Coordinator for Health Information Technology (ONC) was created under Executive Order 13335, ONC has supported the development of standards, services, and policies to support nationwide electronic exchange. ONC's first formal step was the publication of a request for information in November 2004 which sought public input on the development of the nationwide health information network which was originally characterized as a “network of networks.” ONC received 512 comments in response to the RFI and published a report summarizing the comments the following year.
In June 2005, ONC took another step forward toward the development of the nationwide health information network when it issued a request for proposals (RFP) for the development of nationwide health information network prototype architectures. The prototypes sought to test a range of services including the capabilities to query and
In October 2006, NCVHS issued recommendations to ONC on a minimum, but critical, set of functional requirements for nationwide electronic health information exchange to take place. These recommendations sought to accommodate diverse architectures across networks and systems
In fall 2007 and spring 2008, building on the experiences gained and lessons learned in the prototype phase, ONC awarded contracts and grants to organizations to conduct nationwide health information network trial implementations.
Also during this time, NCVHS published informative reports with recommendations related to how entities engaged in electronic exchange activities but who are not covered by HIPAA should be treated and the policy issues associated with consent and secondary uses of IIHI.
The prototype and trial implementation phases produced important insights. Most significantly, they identified areas where further technical and policy work would be needed to enable query and retrieve-based electronic health information exchange and they highlighted the potential limitations of a single, multi-party data use agreement. As a result of these insights, ONC shifted its approach from a singular vision focused on the establishment of a network of networks to one in which the Federal government could serve as the facilitator of diverse approaches to electronic exchange through the specification of nationally-accepted standards, services, and policies. This transition was based in part on the recognition that there could be multiple types of electronic exchange networks all built on the same foundational building blocks of standards, services, and policies.
Beginning in 2009, Federal and non-Federal entities participating in the trial implementations began securely exchanging health information bound by the parameters established in a “production DURSA.” This confederation of entities is referred to as the “Nationwide Health Information Network Exchange” or “the Exchange,” and relies on the DURSA to help structure a governance framework. To become a participant in the Exchange, an organization must sign the DURSA and also must pass an “onboarding”
Presently, a growing number of organizations are exchanging health information as part of the Exchange. Participants in the Exchange are engaged in production activities that include: The exchange of summary patient records for care coordination, including health information that is part of the Virtual Lifetime Electronic Record and which is jointly sponsored by the Departments of Defense and Veterans Affairs; the exchange of summary patient records for Social Security Administration disability determination purposes; and biosurveillance and case reporting to the Centers for Disease Control and Prevention. These use cases have helped to define and evolve a set of specific standards, services, and policies included in the nationwide health information network's growing electronic exchange portfolio.
Many lessons can be learned from the Exchange's production activities. For instance, the Exchange identified one type of governance model for nationwide electronic health information exchange with the DURSA, which relies upon a “Coordinating Committee” and “Technical Committee,” to develop exchange policies and technical interoperability requirements for the participants. Another important lesson learned was that the member organizations identified a need for more specific policies and greater consistency in implementing the HIPAA Privacy and Security Rules in order to engender sufficient trust among parties with which data would be shared. The Exchange's efforts have aided in the early identification and resolution of policy and technical challenges and helped tee up issues that require broad stakeholder dialogue, such as the policy and technical requirements related to matching patients to their health information.
Payment and delivery reforms—from accountable care organizations (ACOs)
Stage 1 of the Medicare and Medicaid EHR Incentive Programs included several objectives and measures that required or encouraged electronic exchange as an efficient means for an eligible professional, eligible hospital, or critical access hospital to satisfy the objective and measure (e.g., “exchange key clinical information;” “incorporate clinical lab test results;” and “submission to immunization registries”). As we reviewed our standards portfolio in terms of its ability to support meaningful use Stage 1, we determined that we were missing a simple and easily adoptable approach to enable electronic exchange to occur. While many HIT vendors supported some kind of planned electronic exchange capability prior to meaningful use Stage 1, many did not follow a common set of standards or included a proprietary mechanism that would make it difficult for providers using different systems to easily exchange clinical information to support patient care.
In March 2010, after public meetings held by the HIT Policy Committee, ONC coordinated the launch of the “Direct Project” to identify the standards, services, and policies necessary to enable a simple, secure, scalable, standards-based way for participants to send authenticated, encrypted health information directly to known, trusted recipients over the Internet. The Direct Project focused on what would be necessary to transport health information regardless of the clinical content of the information to be exchanged. A primary goal of the Direct Project was to support secure, efficient, and low cost exchange of health information and to make it possible for eligible health care providers to satisfy some of the meaningful use Stage 1 objectives and associated measures that require electronic exchange.
Unlike the Exchange, the Direct Project cannot rely on a governance framework provided by the DURSA and “onboarding” procedures. While both initiatives are considered part of ONC's nationwide health information network activities, each was established to address different electronic exchange requirements and contribute different standards, services, and policies to the nationwide health information network's portfolio. A basic analogy that may help explain the relationship between the nationwide health information network, the Exchange, and the Direct Project is as follows: The nationwide health information network is akin to the “Internet”—an electronic environment in which the use of a common set of standards, services, and policies will allow a group of entities to exchange information. The nationwide health information network comprises multiple approaches that one could use to electronically exchange electronic health information among a variety of stakeholders. The Exchange could be compared to a consortium using a secure “Intranet,” in which only approved members can gain access after receiving the appropriate security credentials and agreeing to the Intranet's terms of use. Continuing this analogy, the Direct Project is like secure email or even secure instant messaging, whereby two entities that already share a trust relationship with each other can use relatively simple technical means to electronically exchange health information.
f. The Health Information Technology Policy and Standards Committees' Work on the Nationwide Health Information Network.
In September 2010, the HIT Policy Committee, which is one of two statutorily established Federal Advisory Committees that provide advice to the National Coordinator, formed the nationwide health information network Governance Workgroup (Governance Workgroup) and charged it with “draft[ing] a set of recommendations on the scope and process of governance for nationwide health information exchange, including measures to ensure accountability and oversight.”
• Identified nine core principles according to which the nationwide health information network should be governed. These principles included: transparency and openness; inclusive participation and adequate representation; effectiveness and efficiency; accountability; federated governance and devolution; clarity of mission and consistency of actions; fairness and due process; promote and support innovation; and finally, evaluation, learning and continuous improvement.
• Emphasized that the nationwide health information network should be considered a preferred approach for nationwide health information exchange.
• Identified the responsibilities for the Federal government in governance of the nationwide health information network. These should include: (1) Leading the development of fundamental “conditions” to facilitate greater trust and interoperability in an electronic health information exchange environment and promote the adoption of those conditions through various policy levers; (2) Recognizing existing state authorities across all relevant domains and facilitating coordination and harmonization with states and other entities as needed; (3) Requiring exchange with Federal agencies to be conditioned on compliance with the conditions; and (4) Sharing the responsibility of governance with other entities to reflect a “governance of governances.”
• Optimize broad stakeholder input, including consumers, to facilitate the conditions needed for greater trust and interoperability in electronic exchange.
• Establish an initial set of conditions and a process to incrementally add to or modify the conditions over time. Establish a process to validate
• Ensure accountability through oversight.
Most recently, the HIT Standards Committee established a subcommittee, the nationwide health information network Power Team, in June 2011.
As we consider how best to implement our statutory authority to establish a governance mechanism for the nationwide health information network, we believe it would be critical to adopt a suite of conditions for trusted exchange (CTEs) to serve as the “rules of the road” for trusted, secure, and interoperable electronic exchange, nationwide. We believe that the CTEs could serve as a foundational set of requirements that could be used in one or more combinations to support many different forms of electronic exchange. CTEs appear to best be grouped into three categories: safeguards, interoperability, and business practices.
•
•
•
Question 1:
An important component of the governance mechanism we are considering would be the establishment of a voluntary framework for entities that facilitate electronic exchange to be validated to CTEs adopted for the exchange services or activities they are capable of supporting. Upon successful validation to the CTEs, an entity would be recognized as a NVE and thus would be recognized as an entity that would be accountable for the electronic exchange services or activities it performs in accordance with the CTEs. Given the incremental CTE adoption approach we expect to take, we also anticipate that the recognition of NVEs would incrementally expand along with the diversity of the electronic exchange services or activities they are able to perform. Thus, we could see providing NVEs or new entities with other categorical recognition(s) for the electronic exchange services or activities they are capable of supporting in accordance with subsequently adopted CTEs. Additionally, this validation process would support an evolution, in the U.S. and internationally, towards engaging accountability agents as a supplemental means for ensuring that organizations and providers involved in the management, storage, and transport of IIHI adhere to policies and practices that protect the privacy and security of information.
It is also our expectation that validation would be voluntary. In other words, the validation process established as part of the governance mechanism would not be mandatory and would only apply in so far as an entity deciding that there would be value (e.g., prestige, competitive advantage) in seeking validation. That said, once the validation process is established, much like other government programs on which subsequent policy objectives could be leveraged, it would be possible for other public and private organizations to specify NVE recognition as a condition in awarding contracts, procurements and/or in other situations where validation would be beneficial.
Question 2:
Question 3:
Question 4:
Question 5:
Question 6:
Question 7:
We intend to use notice and comment rulemaking to establish the structures, processes, and initial requirements that would be necessary for the governance mechanism to operate. Under the governance mechanism we are considering, ONC would retain certain responsibilities to ensure the governance mechanism's proper implementation, but would also seek to delegate, where possible and appropriate, certain other responsibilities that we believe can best be performed by the private sector.
Generally speaking, we anticipate that the National Coordinator's and ONC's responsibilities as part of the governance mechanism would include:
• Endorsing and adopting CTEs, in accordance with the National Coordinator's authority at section 3001(c)(1)(A) and processes identified at section 3004 under the PHSA, and publishing interpretative guidance on the means to comply with adopted CTEs;
• Facilitating the receipt of input from the HIT Policy and Standards Committees and other interested parties
• The selection and oversight processes for an accreditation body that would be responsible for accrediting organizations interested in becoming validation bodies;
• Authorizing and overseeing validation bodies which would be responsible for validating that eligible entities have met adopted CTEs;
• Administering a process to classify the readiness for nationwide adoption and use of technical standards and implementation specifications to support interoperability related CTEs; and
• Overall oversight of all entities and processes established as part of the governance mechanism.
Question 8:
Similar to the roles and responsibilities we established under the permanent certification program for HIT (76 FR 1262), we could see establishing a process by which the National Coordinator would approve a single body to accredit and oversee “validation bodies.” The process considered in this RFI, however, would differ from the HIT certification programs in that validation would evaluate an entity's conformance to adopted CTEs as opposed to a particular product's (
Question 9:
Question 10:
Question 11:
Question 12:
We anticipate that potential NVEs could include, but would not be limited to, the following types of entities that provide services to facilitate electronic health information exchange: EHR developers; regional, state, local or specialty-based health information exchanges; health information service providers; State agencies; Federal agencies, and integrated delivery networks.
In order to provide a baseline level of trust in NVEs, we think that it could be helpful to establish upfront eligibility criteria such as the ones discussed below. We are considering that entities interested in becoming NVEs would need to:
• Meet all solvency and financial responsibility requirements imposed by the statutes and regulatory authorities of the State or States in which it, or any subcontractor performing some or all of its functions, would serve. We are considering requiring a prospective NVE make some type of financial disclosure filing as well as provide evidence that it has a surety bond or some other form of financial security.
• Have the overall resources and experience to fulfill its responsibilities in accordance with the CTEs when performing health information exchange services. We are considering whether an entity would need to have at least one year of experience.
• Serve a sufficient number of providers to permit a finding of effective and efficient administration. Under this criterion, however, no prospective NVE would be deemed ineligible if it only served providers located in a single State.
• Have to be a valid business or governmental entity operating in the United States.
• Have not had civil monetary penalties, criminal penalties, or damages imposed, or have been enjoined for a HIPAA violation (by HHS, the Department of Justice, or State Attorneys General) within two years prior to seeking validation.
• Not be listed on the Excluded Parties List System maintained by the General Services Administration which includes information regarding entities debarred, suspended, proposed for debarment, excluded or disqualified under the non-procurement common rule, or otherwise declared ineligible from receiving Federal contracts, certain subcontracts, and certain Federal assistance and benefits.
• Not be listed on the List of Excluded Individuals and Entities maintained by the Office of Inspector General (OIG). The OIG has the authority to exclude individuals and entities from Federally funded health care programs pursuant to sections 1128 and 1156 of the Social Security Act and maintains a list of all currently excluded individuals and entities called the List of Excluded Individuals and Entities.
We include the HIPAA civil money penalty criterion as we expect that most entities that would qualify as NVEs would be business associates of covered entities as defined in the HIPAA Rules, or in some cases covered entities themselves, and therefore, would be directly subject to the requirements and standards of the HIPAA Privacy,
Question 13:
Question 14:
Question 15:
Question 16:
Throughout the history of the nationwide health information network, a strong emphasis has been placed on ensuring broad stakeholder participation in the network's development and governance.
Question 17:
As the HIT Policy Committee and stakeholder feedback over time have indicated, any governance mechanism established for the nationwide health information network would need to include some method for monitoring and transparent oversight. To mitigate confusion in the marketplace, protect consumer rights, and help ensure health care provider satisfaction, we believe a process to receive and address complaints as well as a process to revoke an NVE's status would need to exist. While the revocation of an NVE's status may be the most severe “penalty” ONC could impose, we also realize that when a penalty is so substantial there can be a tendency to pursue other measures to correct an identified issue except in the case of severe violations.
We also anticipate that monitoring and transparent oversight could be conducted by different stakeholders as part of nationwide health information network governance. While ONC could retain overall authority for monitoring and oversight, we also believe that the accreditation body and validation bodies involved in determining compliance with the adopted CTEs could also play oversight roles. For example, validation bodies would be responsible for monitoring and overseeing the NVEs they have validated. Furthermore, other modes of monitoring and enforcement could also play a role, such as: voluntary industry self-policing, a complaint/ombudsman role for a non-governmental entity, civil lawsuits. That said, we do not believe that some of these enforcement or monitoring methods would necessarily be effective, particularly in light of the voluntary validation framework we are considering. Moreover, Federal agencies including the Federal Trade Commission (FTC) and the HHS Office for Civil Rights (OCR) have enforcement authority within their regulatory jurisdictions and can already act on complaints of certain improper conduct. For instance, the FTC could investigate alleged misconduct related to validation status through the Federal Trade Commission Act (15 U.S.C. 45(a) and 52). A negative determination could lead to revoking an NVE's public representation of conformance to the adopted CTEs. Similarly, OCR, which enforces the HIPAA Privacy and Security Rules, could investigate alleged violations of the HIPAA Rules, the outcome of which could impact an NVE's validation of conformance to certain CTEs.
Question 18:
Question 19:
If we were to pursue a validation approach, we believe that entities that have been successfully validated in accordance with the CTEs should be able to publicly represent themselves in some manner as complying with the adopted CTEs. We think this public representation could stimulate market demand for NVE services in the health information exchange marketplace.
We assume that NVEs would need to conform to some CTEs regardless of the specific electronic health information exchange service(s) or activities provided. We believe this approach could create a core trust baseline for all NVEs and that such commonality could strengthen the public's trust of NVEs and NVEs' trust of other NVEs. Finally, we assume that some NVEs could perform services or activities unrelated to adopted CTEs. In such cases, we believe it would be necessary for there to be a clear distinction between the recognition an NVE receives under the governance mechanism and the other services or activities it supports but for which validation has not been provided.
Question 20:
Question 21:
We recognize and expect that electronic health information exchange capacity will continue to accelerate over the coming years. With this additional capacity, new ways for individuals to fully participate in their health care, and activities to harness this capacity to improve population health and develop a “learning health care system” will be available. As we closely watch other activities in the public and private sectors, we anticipate that the CTEs we are considering in this first rulemaking will need to be revised, that other CTEs will need to be retired to reflect the changing electronic health information exchange landscape, and that new CTEs will be needed. Our goal in discussing this initial set of CTEs is to identify a starting point, and then eventually support as broad a range of electronic exchange activities as practicable given the maturity of technical standards and policies for electronic exchange. The following discussion reflects ONC's current thinking regarding a first set of CTEs that could be adopted to support a variety of electronic exchange activities, nationwide.
A Code of Fair Information Practice was first articulated by an Advisory Committee to the Secretary of the US Department of Health, Education, and Welfare in a 1973 report,
We assume that most NVEs will perform services involving the use or disclosure of IIHI on behalf of health plans and health care providers. Accordingly, we believe that nearly all NVEs would be HIPAA business associates of health plans and health care providers and, pursuant to the HITECH Act, subject to the use and disclosure standards and implementation specifications of the HIPAA Privacy Rule as well as the security standards and implementation specifications in the HIPAA Security Rule. We expect these NVEs would comply with these rules.
Although the HIPAA Privacy and Security Rules would apply to nearly all NVEs in some way, the governance mechanism and specifically the CTEs would, in part, serve to address limited instances of electronic exchange not covered under the privacy and security protections afforded by the HIPAA Privacy and Security Rules. First, the CTEs would extend privacy and security requirements to non-HIPAA-covered entities and non-HIPAA-business associates that engage in nationwide electronic exchange. Second, the CTEs would establish additional requirements not currently addressed by the HIPAA Privacy and Security Rules. Finally, the HIPAA Privacy Rule sets required baseline protections and was not necessarily intended to reflect best practices
•
For most health care organizations in the United States, the HIPAA Security Rule is the preeminent framework for securing electronic health information. Published in February 2003, the HIPAA Security Rule sets forth a flexible and scalable approach to apply to a broad range of HIPAA covered entities, including covered provider practices (large and small), payers, and health care clearinghouses, all of which have different needs and resources with respect to securing electronic health information in their environments. In providing this flexibility, the HIPAA Security Rule provides both “required” and “addressable” implementation specifications. Covered entities must meet the “required” implementation specifications, but are permitted to take equivalent, alternative approaches to “addressable” implementation specifications if the covered entity has determined that such implementation specifications would not be reasonable or appropriate for the entity's particular environment. In 2009, with the enactment of the HITECH Act, Congress specified that sections 164.308, 164.310, 164.312, and 164.316 of title 45 of the Code of Federal Regulations shall apply to business associates in the same manner as they apply to covered entities. Accordingly, and because we believe that nearly all NVEs will be business associates of covered entities (or covered entities themselves), we believe that mirroring this statutory requirement is the best starting point for NVEs' overall security practices. That being said, one of our main goals in establishing a governance mechanism for the nationwide health information network is to establish a consistent trust baseline for electronic exchange. Thus, we believe that in order to strengthen the public's trust of NVEs and NVEs' trust of other NVEs that all of the HIPAA Security Rule's “addressable” implementation specifications should be required for all NVEs. We believe that this approach provides greater certainty and more uniformity with respect to the security practices NVEs would need to follow.
Question 22:
Question 23:
•
We believe that it is important for an NVE to offer the parties for which it facilitates exchange a high degree of certainty that only authorized parties are able to use its exchange services. The requirement to authenticate and authorize the parties for which the NVE facilitates exchange could be accomplished either directly or indirectly by the NVE. In the case of the latter, the NVE would need to require the party for which it facilitates electronic exchange to perform authentication and authorization in order to be in compliance with this CTE. We believe that if an NVE cannot directly authenticate and authorize the parties for which it facilitates exchange (which could be at an organizational level), that it would be critical for the NVE to “flow down” these responsibilities and obtain reasonable assurance from the party(ies) for which it facilitates exchange that only authenticated and authorized personnel are able to access electronic exchange services it facilitates. For example, if the NVE were to facilitate an electronic exchange for a hospital, it would be able to satisfy this CTE (indirectly) by ensuring that the hospital had a process in place to authenticate and authorize its own personnel's use of the exchange services provided by the NVE. In proposing the adoption of this CTE, we would also look to NIST SP800–63(v1.02) “Electronic Authentication Guideline” and any other best practices
Question 24:
Question 25:
Question 26:
•
In considering the recommendations that we received from the HIT Policy Committee,
In terms of providing meaningful choice, we believe that an NVE should be required to do the following to satisfy this CTE, either: directly provide the patient with meaningful choice regarding the exchange of their IIHI; or ensure (with some means of verification) that the health care provider for which it facilitates electronic exchange has provided individuals with meaningful choice regarding the exchange of their IIHI.
Mindful that the HIT Policy Committee's recommendations are premised on the belief that different means of exchange may invoke different privacy and security concerns, we are considering, within the context of Interoperability CTE I–1,
Question 27:
Question 28:
Question 29:
Question 30:
•
Encryption is often regarded as a best practice for maintaining the confidentiality of IIHI transmitted across networks. To satisfy this condition, we believe that an NVE would need to be able to either (1) exchange already encrypted IIHI, (2) encrypt IIHI before exchanging it, or (3) establish and make available encrypted channels through which electronic exchange could take place (or do any combination of the above). We would expect NVEs to implement industry best practices for doing so. In order to provide some degree of flexibility, we would establish a general CTE for encryption of data in motion and publish more specific guidance on best practices. These requirements and guidelines would be consistent with the guidance provided by HHS' OCR related to breach notification and standards for rendering unsecured protected health information unusable, unreadable, or indecipherable to unauthorized individuals.
Question 31:
•
Under the HIPAA Privacy Rule (45 CFR 164.520), individuals have the right
The type of notice contemplated by this CTE would differ in certain aspects from a HIPAA Privacy Rule NPP. First, rather than a notice directed only to consumers whose health information is being used or disclosed, we believe that NVEs should clearly give advance notice to those who use their services, as well as to the general public, why they collect IIHI, how it is used, and to whom and for what reason it is disclosed. Second, with the goal of increasing public trust and enabling electronic exchange, we believe that an NVE should give notice about what it actually does do, rather than what it is legally permitted to do, with the IIHI for which it is responsible for exchanging. Third, we believe a NVE should give explicit and specific notice about certain uses and disclosures of health information, such as the specific circumstances when it will de-identify health information and provide it to third parties. For example, if the NVE de-identifies IIHI and then provides such de-identified information to pharmaceutical or research companies, it would need to include a description of this action in its notice to satisfy the CTE described above. This would address the concerns of some stakeholders, including certain members of the HIT Policy Committee, that certain persons and organizations may not be fully aware that an entity transmitting data on their behalf may de-identify their data and then share such de-identified data with third parties. We also believe this CTE is consistent with the privacy and security “core values” recommended by the HIT Policy Committee on September 1, 2010.
Question 32:
Question 33:
Question 34:
Question 35:
Question 36:
•
As noted above, some stakeholders, as well as the HIT Policy Committee, have expressed concern that certain persons may not be fully aware that someone transmitting data on their behalf may use de-identified data for profit seeking opportunities. This scenario appears to have raised two concerns: the potential that certain recipients of de-identified data possess their own established databanks and may be able to re-identify the data by comparing it to existing data; and providers' losing trust in a system in which the data for which they are responsible, although de-identified, is monetized. We recognize that under the HIPAA Privacy Rule, a provider could prohibit a business associate in its business associate agreement from de-identifying data and then subsequently using the de-identified data. However, we are aware of circumstances where certain business associates have drafted business associate agreements that allow for such de-identification of data for the business associates' purposes. Additionally, smaller covered entities may lack the economic resources and expertise necessary to effectively negotiate business associate agreements, in particular with respect to preventing the commercialization of health information. We believe that having a CTE prohibiting NVEs from using or disclosing de-identified health information for economic gain would alleviate the concerns that have been raised about potential re-identification of the data.
Question 37:
Question 38:
•
We are considering requiring NVEs to demonstrate that the systems and processes they have in place can assure users that its services will be available when needed. We consider high availability to mean near 24 hours a day, 7 days a week availability. In other words, to demonstrate compliance with this CTE, an NVE would need to ensure its services would be available at all times, except for very limited, scheduled periods of time. We believe such a requirement is necessary because the need to engage in electronic exchange may occur at any time. In cases where two or more NVEs are necessary to route health information from the source to its ultimate destination, NVEs should have reasonable assurances that the other parties on which they depend to route health information will be available for electronic exchange.
Question 39:
•
The HIPAA Privacy regulations at 45 CFR 164.524 provide individuals with a right to access information maintained in a Designated Record Set (as defined at 45 CFR 164.501). However, this right may not extend to all IIHI that is used or assembled by NVEs to facilitate electronic exchange. Consistent with the “Access” principle expressed in the Privacy and Security Framework, we are considering adopting a CTE that would require an NVE to provide individuals with access to any information the NVE creates that results in a unique set of IIHI. In this context, and for the purpose of this CTE, we consider the IIHI that an NVE assembles or aggregates itself and retains on an individual to constitute a “unique set of IIHI” because the NVE would be the only party through which this information could be accessed (i.e., the individual would not be able to readily recreate the NVE's unique set of IIHI by requesting access to the information held by each of his or her providers that have a relationship with the NVE). For example, if multiple health care providers seek to electronically exchange health information for a given patient, then the NVE facilitating these exchanges would be in a position to aggregate the patient data it receives thus generating a unique
Question 40:
•
Building on the Safeguard CTE [S–8] above and consistent with the “Correction” principle in the Privacy and Security Framework, we believe that any NVE that must provide an individual with the right to access the unique set(s) of IIHI it maintains, should also be required to provide individuals with the right to request a correction and/or annotation to this unique set of IIHI.
Question 41:
Question 42:
•
The HIPAA Privacy Rule does not set specific requirements for when a health care provider may request information maintained by other providers for treatment purposes. The duty to protect health information is placed almost exclusively on the discloser, and the requester bears little responsibility.
In theory, a query and response model would allow a provider to seek records of unknown individuals by querying on a particular diagnosis or demographic information and retrieve all records responsive to the query.
Question 43:
Question 44:
As previously described, Interoperability CTEs would focus on the technical conditions for electronic exchange. This would include the standards and implementation specifications needed to ensure that electronic health information can be exchanged in a manner that allows for consistent and meaningful interpretation across systems. While this initial set of Interoperability CTEs primarily focuses on transport standards and conditions needed to support planned electronic exchange, we believe that they could also include, where appropriate or necessary for electronic exchange to take place, additional specificity in the form of content exchange standards and vocabulary/code set standards.
This Interoperability CTE would address “planned” electronic exchange scenarios when the sender and receiver are known (
To satisfy this CTE, we are considering requiring an NVE to implement and use one of two types of transport specifications. The first type includes the transport specifications developed under the Direct Project, which are the Applicability Statement for Secure Health Transport, and the Cross-Enterprise Document Reliable Interchange (XDR) and Cross-Enterprise Document Media Interchange (XDM) for Direct Messaging. The second type includes the transport specification developed under the Exchange, SOAP–Based Secure Transport RTM version 1.0.
The Applicability Statement for Secure Health Transport specification describes how electronic health information can be securely transported using simple mail transport protocol (SMTP), Secure/Multipurpose Internet Mail Extensions (S/MIME), and X.509 certificates. The XDR and XDM for Direct Messaging specification describes the use of XDR and XDM as a means to transport electronic health information and would serve as a bridge between entities using/following web services and SMTP transport methods. We believe these two options would make it possible for a majority, if not all,
Question 45:
Question 46:
•
Digital certificates are used to create a high-level assurance that an organization exchanging electronic health information is the entity it claims to be. Therefore, having common baseline expectations for establishing digital certificates and making the public keys discoverable are foundational elements for rapid, scalable electronic exchange. In this regard, in April 2011, the HIT Standards Committee approved and transmitted a set of recommendations on digital certificates for the National Coordinator to consider. Digital certificates are used both as part of the transport specifications developed under the Direct Project as well as the Exchange to authenticate entities involved in electronic exchange. For the purposes of this CTE, we are considering adopting as requirements the recommendations expressed by the HIT Standards Committee, specifically its recommendations on the requirements and evaluation criteria for digital certificates. We are also considering its second recommendation with respect to cross-certifying with the Federal Bridge Certificate Authority (the Federal Bridge).
Question 47:
Question 48:
•
The intent of this CTE is to provide guidance for NVEs to verify and match message subjects (
Before exploring the specifications for patient matching, the Power Team first developed a set of baseline assumptions around the appropriate levels of specificity and sensitivity. For this use case, the Power Team assumed that specificity was more critical than sensitivity and that specificity of at least 99.9% and sensitivity of 95% would be an appropriate range for ensuring a high level of matching accuracy and accountability. These levels were used because sensitivities lower than 95% could result in incomplete views of the patient's record and specificities lower than 99.9% could result in incorrect matching, putting both the patient and the inappropriately matched individual at risk.
In August 2011, the Patient Matching Power Team presented several recommendations relating to patient matching to the HIT Standards Committee, which were considered, adopted and submitted to the National Coordinator. Its recommendations included a general principle regarding matching sensitivity and specificity and suggested that a base set of patient attributes should be selected based on demonstrated achievement of those levels. The HIT Standards Committee also recommended that health care providers give patients more of a role in verifying attributes used for matching and that HIT developers should provide a method for identifying missing or unavailable data to be identified and further, that basic validity checks be performed on patient attributes (such as only accepting dates in the past for dates of birth, no more than six 9s or six 0s in a row in the Social Security Number). Finally, the HIT Standards Committee recommended that patient query patterns should follow the “Exchange patient query implementation guide” and that the CDA R2 header formats should be used to represent patient attributes. It was also noted that responses to patient queries should not return any patient attributes that were not included in the original query, but that it may be appropriate for the response to indicate other data that could be useful in matching this patient.
Question 49:
Question 50:
Question 51:
The third category of CTEs we are considering would focus on an NVE's business practices, including the operational and financial practices to which an NVE would need to adhere. We believe this category of CTEs would be necessary in order to ensure electronic exchange among NVEs takes place unimpeded.
•
Generally speaking, this CTE expresses our belief that any health care provider using an NVE should be able to engage in unimpeded, planned electronic health information exchange with another health care provider using a different NVE. We believe that requiring NVEs to meet this CTE would instill greater confidence in planned electronic health information exchange and among health care providers who would rely on NVEs. In satisfying this CTE, an NVE could not impose business requirements on other NVEs, such as fees that would otherwise prevent another NVE from exchanging electronic
Question 52:
Question 53:
Question 54:
•
In order for planned electronic exchange to take place, and to satisfy this CTE, NVEs would need to make openly available to other NVEs or NVE customers certain services they offer. For example, for electronic exchange to take place following the Direct Project specifications, it would be necessary for an NVE to make openly available a directory of addresses of potential recipients and locatable public keys. While we recognize that the industry is still building its capacity to address this CTE, we believe that it is achievable.
•
In order to assess our progress towards nationwide availability and use of health information exchange, it would be useful to have data about the use of NVE services, the types of users, and transaction volume for their validated services. The data should be collected and made available at the aggregate level so as not to expose information about specific customers or patients.
Question 55:
Stakeholders are encouraged to provide feedback on this initial set of CTEs and in submitting comments suggest other CTEs that we should also consider. The following table summarizes the CTEs as presented in this RFI.
One approach for implementing nationwide electronic exchange can be observed through the Nationwide Health Information Network Exchange. As we described in the background section of this RFI, the Exchange is a confederation of trusted entities that have passed certain requirements for participation. One such requirement includes signing the DURSA, which serves as a legal framework for sharing electronic health information among participants in the Exchange. The DURSA includes “performance and service specifications” which the participating members agree to use in implementing secure electronic exchange. The most recent specifications used by participants in the Exchange can be found on ONC's Web site.
Question 56:
Question 57:
Question 58:
Question 59:
Assuming we were to pursue an approach that includes the adoption of CTEs as part of a governance mechanism for the nationwide health information network, we expect that additional CTEs and revisions to CTEs would be necessary to accommodate policy maturity and technical changes over time. We believe that an inclusive and transparent process to identify, modify, and retire CTEs would be needed to engage stakeholders and would result in more refined and widely accepted CTEs. The purpose of this process would be to identify and assess current electronic exchange needs and to provide a path for determining how best to address them through the CTEs. We envision that rulemaking could be necessary every two years, most likely on years that would alternate with regulations published for EHR Incentive Programs, to keep the CTEs up-to-date and to permit entities to seek validation to new CTEs for other more complex forms of electronic exchange.
We believe that an approach to a CTE maturity life cycle could start with the identification of “emerging” CTEs, followed by the identification of “pilot” CTEs, followed by “national” candidate CTEs which we would consider sufficiently mature to propose for adoption. We believe that the “pilot” stage could empower greater stakeholder participation in governance and could permit the direct submission of best practices to ONC or through one of our advisory committees. It could also potentially enable validation bodies to provide for validation to pilot CTEs which would provide further input in terms of the CTEs' readiness to be identified as national candidate CTEs. We could see using the HIT Policy Committee and HIT Standards Committee to provide a forum to solicit public input on identifying best practices and piloting CTEs in a manner consistent with their statutory authority. We would further envision that this process would follow the procedures and comport with the requirements of section 3004 and other relevant sections of the PHSA, for the development and adoption of standards, implementation specifications, and certification criteria.
Question 60:
Question 61:
Question 62:
We believe that it would benefit the industry to include as part of the governance mechanism, a formal and transparent process to classify technical standards and implementation specifications that could ultimately be adopted within the Interoperability category of CTEs.
Through this process, technical standards and implementation specifications could be assigned to one of three classifications:
• “
• “
• “
We believe the governance mechanism can and should be used to promote innovation in the health information exchange market. Therefore, we believe with the identification of the Emerging and Pilot standards and implementation specifications, the governance mechanism could encourage groups of HIT stakeholders to test, learn about, and provide feedback on those standards and implementation specifications and their readiness to be promoted to the next classification.
Question 63:
The following figure generally illustrates the classifications discussed above. The upper right hand corner of the figure denotes standards classified as “National,” indicating readiness for national adoption. We highlight the fact that a technical standard could be considered highly mature, albeit, not very adoptable (upper left portion of the figure), or conversely, a standard could also be determined to be highly adoptable, but not very technically mature (lower right portion of the figure). In such instances we would task the HIT Policy and Standards Committees with providing advice on policy and technical justifications for whether a standard with these
Coupled with the annual process to identify, review, and assess standards and implementation specifications, we assume that a discrete set of objective criteria would be necessary to assess whether and when a technical standard or implementation specification should be classified differently. We believe the HIT Policy Committee would have a key role in prioritizing technical standards and implementation specifications needs and the HIT Standards Committee could have an integral role in advising ONC about how to classify such technical standards and implementation specifications. The HIT Standards Committee has had initial discussions on what classification criteria could look like, such as: maturity; market adoption, need; deployment complexity; and the maturity of the underlying technology for a given standard.
Question 64:
Question 65:
As part of an NPRM, we would perform a regulatory impact analysis consistent with Executive Order 12866 and other applicable requirements. The focus of the RFI is to obtain public comment on what would be necessary to launch the structures, processes, and initial requirements to establish a governance mechanism for the nationwide health information network, but also interested in public comment on any publicly available data that we could subsequently use in a future NPRM's regulatory impact statement to determine the costs and benefits of such a governance mechanism.
Question 66:
1. The potential costs of validation;
2. The potential savings to States or other organizations that could be realized with the establishment of a validation process to CTEs;
3. The potential increase in the secure exchange of health information that might result from the establishment of CTEs;
4. The potential number of entities that would seek to become NVEs; and
5. The NVE application and reporting burden associated with the conceptual proposals we discuss.