[Federal Register Volume 77, Number 94 (Tuesday, May 15, 2012)]
[Proposed Rules]
[Pages 28543-28560]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2012-11775]


=======================================================================
-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 171


Nationwide Health Information Network: Conditions for Trusted 
Exchange

AGENCY: Office of the National Coordinator for Health Information 
Technology (ONC), Department of Health and Human Services.

ACTION: Request for information.

-----------------------------------------------------------------------

SUMMARY: 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

[[Page 28544]]

National Coordinator for Health Information Technology to establish a 
governance mechanism for the nationwide health information network 
(section 3001(c)(8) of the Public Health Service Act (PHSA)). This 
request for information (RFI) is being issued to request public comment 
on draft proposals the Office of the National Coordinator for Health 
Information Technology (ONC) is considering in anticipation of 
developing a notice of proposed rulemaking (NPRM) to establish such a 
governance mechanism. This RFI seeks broad input on a range of topics, 
including: The creation of a voluntary program under which entities 
that facilitate electronic health information exchange could be 
validated with respect to their conformance to certain ONC-established 
``conditions for trusted exchange (CTEs);'' the scope and requirements 
included in the initial CTEs; the processes that could be used to 
revise, adopt new, and retire CTEs, including but not limited to the 
standards development and adoption process provided in section 3004 and 
other relevant sections of the PHSA; and a process to classify the 
readiness for nationwide adoption and use of technical standards and 
implementation specifications to support interoperability related CTEs.

DATES: 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.

ADDRESSES: 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.
     Federal eRulemaking Portal: Follow the instructions for 
submitting comments. Attachments should be in Microsoft Word or Excel, 
Adobe PDF; however, we prefer Microsoft Word. http://www.regulations.gov.
     Regular, Express, or Overnight Mail: Department of Health 
and Human Services, Office of the National Coordinator for Health 
Information Technology, Attention: Governance RFI, Hubert H. Humphrey 
Building, Suite 729D, 200 Independence Ave. SW., Washington, DC 20201. 
Please submit one original and two copies.
     Hand Delivery or Courier: Office of the National 
Coordinator for Health Information Technology, Attention: Governance 
RFI, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave. 
SW., Washington, DC 20201. Please submit one original and two copies. 
(Because access to the interior of the Hubert H. Humphrey Building is 
not readily available to persons without federal government 
identification, commenters are encouraged to leave their comments in 
the mail drop slots located in the main lobby of the building.)
    Inspection of Public Comments: All comments received before the 
close of the comment period will be available for public inspection, 
including any personally identifiable or confidential business 
information that is included in a comment. Please do not include 
anything in your comment submission that you do not wish to share with 
the general public. Such information includes, but is not limited to: a 
person's social security number; date of birth; driver's license 
number; state identification number or foreign country equivalent; 
passport number; financial account number; credit or debit card number; 
any personal health information; or any business information that could 
be considered to be proprietary. We will post all comments received 
before the close of the comment period at http://www.regulations.gov.
    Docket: For access to the docket to read background documents or 
comments received, go to http://www.regulations.gov or the Department 
of Health and Human Services, Office of the National Coordinator for 
Health Information Technology, Hubert H. Humphrey Building, Suite 729D, 
200 Independence Ave. SW., Washington, DC 20201 (call ahead to the 
contact listed below to arrange for inspection).

FOR FURTHER INFORMATION CONTACT: Steven Posnack, Director, Federal 
Policy Division, Office of Policy and Planning, Office of the National 
Coordinator for Health Information Technology, 202-690-7151.

SUPPLEMENTARY INFORMATION: 

Acronyms and Abbreviations

ACO Accountable Care Organization
ARRA American Recovery and Reinvestment Act
CDA Clinical Document Architecture
CEHRT Certified EHR Technology
CTEs Conditions for Trusted Exchange
DURSA Data Use and Reciprocal Support Agreement
EHR Electronic Health Record
FIPPS Fair Information Practice Principles
HIPAA Health Insurance Portability and Accountability Act of 1996
HIT Health Information Technology
HITECH Health Information Technology for Economic and Clinical 
Health
IEC International Electrotechnical Commission
IIHI Individually Identifiable Health Information
ISO International Organization for Standardization
NVEs Nationwide Health Information Network Validated Entities
NCVHS National Committee on Vital and Health Statistics
NPRM Notice of Proposed Rulemaking
PHSA Public Health Service Act
PHI Protected Health Information
OCR Office for Civil Rights
OIG Office of the Inspector General
ONC Office of the National Coordinator for Health Information 
Technology
RFI Request for Information
RFP Request for Proposal
RLS Record Locator Services
S&I Standards and Interoperability
S/MIME Secure/Multipurpose Internet Mail Extensions
SMTP Simple Mail Transport Protocol
XDM Cross-Enterprise Document Media Interchange
XDR External Data Representation

Table of Contents

I. Background
    A. Introduction
    B. Governance Mechanism Overview
    C. Historical Context
    1. Statutory Authority
    2. Overview of Existing Federal Health Information Privacy and 
Security Standards
    3. Health Information Exchange and the Nationwide Health 
Information Network in Brief
    a. 2001-2004: Conceptualization and Request for Information
    b. 2005-2008: Nationwide Health Information Network Exchange--
Prototypes and Trial Implementations
    c. 2009-Present: Nationwide Health Information Network Limited 
Production and Governance
    d. Private Sector Electronic Exchange
    e. The Direct Project
    f. The Health Information Technology Policy and Standards 
Committees' Work on the Nationwide Health Information Network
II. Request for Information
    A. Establishing a Governance Mechanism
    B. Roles, Responsibilities, and Processes
    1. ONC
    2. The Accreditation Body and Validation Bodies
    3. Eligible Entities for Validation
    a. Eligible Entities
    b. Eligibility Criteria
    4. Stakeholders
    C. Monitoring and Transparent Oversight
    D. Conditions for Trusted Exchange
    1. Safeguard CTEs
    2. Interoperability CTEs
    3. Business Practice CTEs
    E. Request for Additional CTEs
    F. CTE Processes and Standards and Implementation Specification 
Classifications
    1. CTE Lifecycle
    2. Interoperability Conditions for Trusted Exchange--Technical 
Standards and Implementation Specifications Classification Process

[[Page 28545]]

    G. Economic Impact

I. Background

A. Introduction

    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.

B. Governance Mechanism Overview

    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.\1\ Thus, just as the nationwide health information network 
is defined by the evolving set of standards, services, and policies of 
which it is comprised, so too, we believe, should its governance 
mechanism.
---------------------------------------------------------------------------

    \1\ Additional information on the Exchange can be found on ONC's 
Web site at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__nhin_exchange/1407.
---------------------------------------------------------------------------

    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.
     Adoption of ``conditions for trusted exchange'' (CTEs). 
CTEs would reflect the nationwide health information network's 
portfolio of standards, services, and policies and would be 
incrementally added to and refined over time. The initial set of CTEs 
included in this RFI conceptually represent many of the CTEs that we 
believe are foundational for enabling trusted nationwide electronic 
exchange to occur, regardless of the form of electronic exchange in 
which one engages. CTEs would be established under three categories: 
interoperability; safeguards; and business practices. We believe that 
CTEs generally would constitute ``standards'' and ``implementation 
specifications'' as described in the HITECH Act for purposes of 
conducting electronic exchange under the auspices of the nationwide 
health information network.
     Establishment of a voluntary framework for entities that 
facilitate electronic exchange to be validated to CTEs adopted for the 
electronic exchange services or activities they are capable of 
supporting. This framework would be similar to the health information 
technology (HIT) certification programs ONC has already

[[Page 28546]]

established via regulation (76 FR 1262),\2\ but would focus on the 
services and activities the entities perform in facilitating electronic 
exchange and not exclusively on HIT itself. Upon successful validation 
to adopted CTEs an entity would be recognized as a nationwide health 
information exchange network validated entity (NVE) and thus become 
responsible for performing electronic exchange services in accordance 
with the adopted CTEs.
---------------------------------------------------------------------------

    \2\ Information on ONC's Permanent Certification Program for HIT 
can be found on ONC's Web site at: http://origin.www.gpo.gov/fdsys/pkg/FR-2011-01-07/pdf/2010-33174.pdf.
---------------------------------------------------------------------------

     Approaches for monitoring and transparent oversight. Such 
approaches would seek to ensure the integrity of the governance 
mechanism by protecting consumer rights, instilling industry-wide 
confidence in the services performed by NVEs, and provide a way to 
receive and address complaints as well as a process to revoke an NVE's 
validation status.
     Establishment of processes that could be used to adopt, 
revise, and retire CTEs that are no longer appropriate. This would 
entail developing a CTE maturity lifecycle process to identify, modify, 
and retire CTEs over time.
     Establishment of a process to classify the readiness for 
nationwide adoption and use of technical standards and implementation 
specifications to support interoperability related CTEs. Due to their 
rapidly evolving nature, we believe an annual review process to assess 
and classify the maturity and adoptability of technical standards and 
implementation specifications would be beneficial.
    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 \3\ and HIT Standards Committee 
recommendations related to governance of the nationwide health 
information network.\4\ Our overall objectives for establishing a 
governance mechanism for the nationwide health information network are, 
among others, to improve the efficiency of electronic exchange among 
providers, reduce provider implementation costs (such as the cost of 
interfaces), and assure the privacy and security of the data being 
exchanged. Furthermore, we anticipate that an entity's validation to 
the CTEs could be leveraged by others to accomplish other policy and 
programmatic objectives. For example, Federal programs that participate 
in electronic exchange could require the use of entities that are 
validated in accordance with the CTEs adopted as part of the nationwide 
health information network governance mechanism.
---------------------------------------------------------------------------

    \3\ Additional information on the HIT Policy and Standards 
Committees can be found on the ONC Web site at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__federal_advisory_committees_%28facas%29/1149.
    \4\ The HIT Policy Committee and HIT Standards Committee were 
established in law by the HITECH Act and advise and issue 
recommendations to the National Coordinator on issues concerning HIT 
policy and standards.
---------------------------------------------------------------------------

C. Historical Context

1. Statutory Authority
    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.\5\
---------------------------------------------------------------------------

    \5\ Overview information of the nationwide health information 
network can be viewed on ONC's Web site at: http://healthit.hhs.gov/portal/server.pt?open=512&objID=1142&parentname=CommunityPage&parentid=4&mode=2.
---------------------------------------------------------------------------

    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.

[[Page 28547]]

2. Overview of Select Existing Federal Health Information Privacy and 
Security Standards
    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.\6\
---------------------------------------------------------------------------

    \6\ (2000) The HIPAA Privacy Final Rule, published at 65 FR 
82462 at 82471.
---------------------------------------------------------------------------

    The HIPAA Security Rule requires covered entities to establish 
specific administrative, physical, and technical safeguards \7\ for 
electronic protected health information (as such term is defined at 45 
CFR 160.103). The HIPAA Security Rule is scalable and flexible to 
account for the varying size, resources, technology and security risks 
faced by covered entities as they protect the electronic health 
information for which they are responsible.\8\ The HIPAA Security Rule 
includes both standards and implementation specifications, which 
provide instructions for implementing certain of the standards. The 
implementation specifications set out in the Security Rule fall into 
two categories: Those that are ``required'' and those that are 
``addressable.'' An entity must implement a ``required'' implementation 
specification. In contrast, an entity has some flexibility in 
implementing an ``addressable'' implementation specification based on a 
variety of factors, such as, among others, the entity's risk analysis, 
risk mitigation strategy, what security measures are already in place, 
and the cost of implementation.\9\ Encryption, for example, is an 
addressable implementation specification.
---------------------------------------------------------------------------

    \7\ (2010) The regulatory references to administrative, 
physical, and technical safeguards can be found, respectively, at 
part 164, sections 308, 310, and 312 of title 45 of the CFR.
    \8\ More information on the HIPAA Security Rule can be found on 
the Office for Civil Rights Web site at: http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/index.html.
    \9\ An addressable implementation specification requires an 
assessment to determine whether implementation would be reasonable 
and appropriate safeguard in the particular entity's environment. 
Following the assessment, the entity must implement the 
specification if it finds it to be reasonable and appropriate. If 
the outcome of the assessment is that implementing the specification 
would not be reasonable and appropriate, then the entity must (1) 
document why it would not be reasonable and appropriate to implement 
the specification; and (2) implement an equivalent alternative 
measure if reasonable and appropriate.
---------------------------------------------------------------------------

    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.
3. Health Information Exchange and the Nationwide Health Information 
Network in Brief
    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.
a. 2001-2004: Conceptualization and Request for Information
    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.\10\ 
Comments addressed a number of issues such as governance, financing, 
and how the nationwide health information network could be coordinated 
along with local and regional health information exchange projects. 
With respect to governance, comments indicated that ``a well-built 
governance model was needed to develop, set policies and standards for, 
operate, and promote the adoption of a nationwide health information 
network'' and discussed the merits of governance options that ranged 
from significant Federal involvement to a State government-sponsored 
approach to an approach that involved public-private collaboration.
---------------------------------------------------------------------------

    \10\ (2005) ONC. ``Summary of Nationwide Health Information 
Network (NHIN) Request for Information (RFI) Responses.'' Available 
at: http://www.hhs.gov/healthit/rfisummaryreport.pdf.
---------------------------------------------------------------------------

b. 2005-2008: Nationwide Health Information Network Exchange--
Prototypes and Trial Implementations
    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

[[Page 28548]]

retrieve health information from health information exchange 
organizations; the delivery of new data to appropriate recipients; 
patient identification and matching; information locator services; and 
user authentication, access control and other security protections.\11\ 
The prototypes also explored the feasibility and scalability of 
potential nationwide health information network models. In fall 2005, 
ONC awarded four organizations contracts based on the RFP.\12\
---------------------------------------------------------------------------

    \11\ More information on the prototype architectures can be 
viewed on ONC's Web site at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov_nhin_historical_
;background--information/1409.
    \12\ (2005) The archived announcement can be viewed on the HHS 
Web site at: http://archive.hhs.gov/news/press/2005pres/20051110.html.
---------------------------------------------------------------------------

    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 \13\ 
and followed a report issued by NCVHS earlier in the year regarding 
privacy and confidentiality considerations for the nationwide health 
information network.\14\
---------------------------------------------------------------------------

    \13\ (2006) The NCVHS recommendations can be viewed on the NCVHS 
Web site at: http://www.ncvhs.hhs.gov/061030lt.pdf.
    \14\ (2006) ``Privacy and Confidentiality in the Nationwide 
Health Information Network.'' NCVHS, available at: http://www.ncvhs.hhs.gov/060622lt.htm.
---------------------------------------------------------------------------

    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.\15\ Among these organizations' 
accomplishments in the context of the trial implementations was the 
development of data and interface specifications, testing materials, 
and a draft model data use and reciprocal support agreement 
(DURSA).\16\ The DURSA, a single, multi-party agreement, specified the 
rules of engagement and obligations to which all participants in the 
trial implementations agreed to adhere. It also underscored a framework 
for broad-based information exchange among a set of trusted entities, 
reflecting consensus (among the signatories) on policies such as: 
Privacy and security obligations; duties of requesting and responding 
participants; responding participants' legal requirements; and the 
allocation of liability risk.
---------------------------------------------------------------------------

    \15\ (2007) The announcement can be viewed on the HHS Web site 
at: http://www.hhs.gov/news/press/2007pres/10/pr20071005a.html.
    \16\ Additional information on the DURSA can be viewed on the 
S&I Framework Web site at: http://jira.siframework.org/wiki/display/OBTI/DURSA+Overview.
---------------------------------------------------------------------------

    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.17 18 19
---------------------------------------------------------------------------

    \17\ (2007) NCVHS. ``Update to privacy laws and regulations 
required to accommodate NHIN data sharing practices.'' Available at: 
http://ncvhs.hhs.gov/070621lt2.pdf.
    \18\ (2007) NCVHS. ``Enhanced Protections for Uses of Health 
Data: A Stewardship Framework for `Secondary Uses' of Electronically 
Collected and Transmitted Health Data.'' Available at: http://ncvhs.hhs.gov/071221lt.pdf.
    \19\ (2008) NCVHS. ``Individual control of sensitive health 
information accessible via the Nationwide Health Information 
Network.'' Available at: http://ncvhs.hhs.gov/080220lt.pdf.
---------------------------------------------------------------------------

    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.
c. 2009-Present: Nationwide Health Information Network Production and 
Governance
    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'' \20\ test to demonstrate 
capacity to meet the DURSA's technical interoperability requirements.
---------------------------------------------------------------------------

    \20\ More information regarding onboarding procedures can be 
viewed on the S&I Framework Web site at: http://jira.siframework.org/wiki/display/OBTI/Home.
---------------------------------------------------------------------------

    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.
d. Private Sector Electronic Exchange
    Payment and delivery reforms--from accountable care organizations 
(ACOs) \21\ to bundled payments and medical homes--are creating a 
compelling business case for electronic exchange. As a result, 
innovative approaches to electronic exchange are emerging, including 
private networks advanced by hospital systems pursuing ACO status, 
exchange services offered by electronic health record (EHR) vendors, 
and regional and state-level

[[Page 28549]]

health information exchange initiatives. According to a recent KLAS 
survey, the number of active private health information exchange 
entities tripled from 52 in 2009 to 161 in 2010.\22\
---------------------------------------------------------------------------

    \21\ More information on accountable care organizations can be 
viewed on the CMS Web site at: https://www.cms.gov/ACO/.
    \22\ (2011) KLAS Research. ``Health Information Exchanges: Rapid 
Growth in an Evolving Market.''
---------------------------------------------------------------------------

e. The Direct Project
    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.'' \23\ When developing 
its recommendations for the HIT Policy Committee, the Governance 
Workgroup held a series of public meetings and received testimony from 
diverse stakeholders.\24\ After receiving the Governance Workgroup's 
recommendations, the HIT Policy Committee deliberated on them, 
concurred with them, and formally transmitted them to the National 
Coordinator for consideration in December 2010.\25\ The following 
bullets summarize the recommendations to the National Coordinator. The 
recommendations:
---------------------------------------------------------------------------

    \23\ The complete list of Governance Workgroup members can be 
viewed on the ONC Web site at: http://healthit.hhs.gov/portal/server.pt?open=512&mode=2&objID=3080.
    \24\ As background, ONC also provided prior NCVHS reports and a 
2009 whitepaper developed by the National eHealth Collaborative 
which framed certain governance functions.
    \25\ The complete set of recommendations can be viewed on the 
ONC Web site at: http://healthit.hhs.gov/portal/server.pt/gateway/
PTARGS--0--0--6011--1815--17825--43/wci-pubcontent/publish/
onc/public--communities/--content/files/hitpc--transmittal--letter--
gov--wg--dec2010.pdf.
---------------------------------------------------------------------------

     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 \26\ the adopted conditions accounting for the cost 
and burden, and to leverage existing validation methods, processes, and 
entities where appropriate.
---------------------------------------------------------------------------

    \26\ The HIT Policy Committee noted that the term ``validation'' 
was used to generally refer to the process of verifying compliance 
and may include a broad array of possible methods (e.g., self-
attestation, testing, certification of systems, accreditation of 
entities). In our use of the term validation throughout this 
document, we mean it to encompass both accreditation and 
certification.
---------------------------------------------------------------------------

     Ensure accountability through oversight.

[[Page 28550]]

    Most recently, the HIT Standards Committee established a 
subcommittee, the nationwide health information network Power Team, in 
June 2011.\27\ The Power Team was charged with: (1) Creating a draft 
set of criteria for evaluating standards, including factors such as 
adoptability and scalability: (2) evaluating the specifications 
developed for the Exchange and Direct Project initiatives with respect 
to their ability to support nationwide health information exchange; and 
3) recommending those specifications that could be integrated and 
deployed to support the secure transport and exchange of electronic 
health information on a national scale, and identifying where further 
work may be needed. The Power Team held a series of public meetings and 
drafted a set of recommendations \28\ for the HIT Standards Committee, 
noting that while neither the Exchange nor the Direct Project's 
specifications have been proven at scale, there was minimal risk in 
adopting transport mechanisms based on the Direct Project 
specifications. They also recommended simplifying existing 
specifications for the Exchange and investing in pilots for 
representational state transfer (REST) or ``RESTful'' approaches to 
electronic exchange. On September 28, 2011, the HIT Standards Committee 
transmitted a letter to the National Coordinator reflecting the 
analysis conducted by the Power Team.
---------------------------------------------------------------------------

    \27\ The complete list of Workgroup members can be viewed on the 
ONC Web site at: http://healthit.hhs.gov/portal/server.pt?open=512&mode=2&objID=3850.
    \28\ The complete set of recommendations can be viewed on the 
ONC Web site at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__standards_recommendations/1818.
---------------------------------------------------------------------------

II. Request for Information

A. Establishing a Governance Mechanism

    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.
     Safeguards CTEs would focus on the protection of IIHI to 
promote its confidentiality, integrity, and availability and to prevent 
unauthorized or inappropriate access, use, or disclosure.
     Interoperability CTEs would focus on the technical 
standards for the exchange and integration of electronic health 
information so that it is useful for the recipient.
     Business Practices CTEs would focus on the operational and 
financial practices or standards to which NVEs would need to adhere in 
support of trusted electronic exchange.
    Question 1: Would these categories comprehensively reflect the 
types of CTEs needed to govern the nationwide health information 
network? If not, what other categories should we consider?
    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: What kind of governance approach would best produce a 
trusted, secure, and interoperable electronic exchange nationwide?
    Question 3: How urgent is the need for a nationwide governance 
approach for electronic health information exchange? Conversely, please 
indicate if you believe that it is untimely for a nationwide approach 
to be developed and why.
    Question 4: Would a voluntary validation approach as described 
above sufficiently achieve this goal? If not, why?
    Question 5: Would establishing a national validation process as 
described above effectively relieve any burden on the States to 
regulate local and regional health information exchange markets?
    Question 6: How could we ensure alignment between the governance 
mechanism and existing State governance approaches?
    Question 7: What other approaches to exercising our authority to 
establish a governance mechanism for the nationwide health information 
network should we consider?

B. Actors and Associated Responsibilities

    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.
1. ONC
    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

[[Page 28551]]

on revisions to CTEs, new CTEs, and the appropriate retirement of CTEs 
in accordance with processes identified at sections 3002(b)(3) and 
3003(b)(2) of the PHSA;
     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: We solicit feedback on the appropriateness of ONC's 
role in coordinating the governance mechanism and whether certain 
responsibilities might be better delegated to, and/or fulfilled by, the 
private sector.
2. The Accreditation Body and Validation Bodies
    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 (e.g., 
EHR technology) certification to certification criteria. We could 
envision, however, certified HIT (in other venues referred to as 
commercial off-the-shelf software) being used by an entity as a way to 
demonstrate conformance with certain adopted CTEs. For this to occur, 
we anticipate that we would have to adopt specific certification 
criteria that could be used to subsequently certify other types of HIT 
through our already established HIT certification program. The 
accreditation body would be expected to conform to internationally 
accepted standards for accreditation bodies, and in particular, the 
standard ISO/IEC 17011: 2004, jointly published by the International 
Organization for Standardization (ISO) and the International 
Electrotechnical Commission (IEC), which specifies requirements for 
assessing and accrediting certification bodies. The validation bodies 
(upon accreditation by the accreditation body and authorization from 
the National Coordinator) would subsequently perform the validation of 
entities' conformance to adopted CTEs. Ultimately, we believe that 
validation could encompass many different methodologies (e.g., self-
attestation; laboratory testing for standards conformance; 
certification; and accreditation) and could vary depending on the type 
of CTE and the potential burden the validation methodology would 
impose.
    Question 9: Would a voluntary validation process be effective for 
ensuring that entities engaged in facilitating electronic exchange 
continue to comply with adopted CTEs? If not, what other validation 
processes could be leveraged for validating conformance with adopted 
CTEs? If you identify existing processes, please explain the focus of 
each and its scope.
    Question 10: Should the validation method vary by CTE? Which 
methods would be most effective for ensuring compliance with the CTEs? 
(Before answering this question it may be useful to first review the 
CTEs we are considering to adopt, see section ``VI. Conditions for 
Trusted Exchange.'')
    Question 11: What successful validation models or approaches exist 
in other industries that could be used as a model for our purposes in 
this context?
    Question 12: What would be the potential impact of this 
accreditation/validation body model on electronic health information 
exchange, in particular, on the volume and efficiency of exchange in 
local health care markets and provider confidence? What is the best way 
to maximize the benefit while minimizing the burden on providers or 
other actors in the market?
3. Entities Eligible for Validation
a. Eligible Entities
    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.
b. Eligibility Criteria
    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,

[[Page 28552]]

Security and Breach Notification Rules. Additionally, we do not believe 
that it would be appropriate to have an eligibility criterion that 
limits eligible entities to only those that are tax-exempt under 
section 501(c)(3) of the Internal Revenue Code (IRC). Finally, in the 
case of Federal or State governmental entities seeking to become an 
NVE, we anticipate that some of the eligibility criteria we are 
considering may be inapplicable.
    Question 13: Should there be an eligibility criterion that requires 
an entity to have a valid purpose (e.g., treatment) for exchanging 
health information? If so, what would constitute a ``valid'' purpose 
for exchange?
    Question 14: Should there be an eligibility criterion that requires 
an entity to have prior electronic exchange experience or a certain 
number of participants it serves?
    Question 15: Are there other eligibility criteria that we should 
also consider?
    Question 16: Should eligibility be limited to entities that are 
tax-exempt under section 501(c)(3) of the IRC? If yes, please explain 
why.
4. Stakeholders
    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: What is the optimum role for stakeholders, including 
consumers, in governance of the nationwide health information network? 
What mechanisms would most effectively implement that role?

C. Monitoring and Transparent Oversight

    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: What are the most appropriate monitoring and oversight 
methods to include as part of the governance mechanism for the 
nationwide health information network? Why?
    Question 19: What other approaches might ONC consider for 
addressing violations of compliance with CTEs?
    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: What limits, if any, would need to be in place in 
order to ensure that services and/or activities performed by NVEs for 
which no validation is available are not misrepresented as being part 
of an NVE's validation? Should NVEs be required to make some type of 
public disclosure or associate some type of labeling with the validated 
services or activities they support?
    Question 21: How long should validation status be effective?

D. Conditions for Trusted Exchange (CTEs)

    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.
1. Safeguards CTEs
    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, Records, Computers, and the 
Rights of Citizens. The Code is well accepted as a foundation for 
protecting the privacy of individually identifiable information, and 
many privacy laws are based on it, both in the United States and 
abroad.

[[Page 28553]]

The principles that underlie the Code also served in part as the bases 
on which HHS developed its 2008 Nationwide Privacy and Security 
Framework for Electronic Exchange of Individually Identifiable Health 
Information (Privacy and Security Framework).\29\ The Privacy and 
Security Framework includes eight principles that are expected to guide 
the actions of all persons and entities that participate in a network 
for the purpose of electronic exchange of IIHI. Wherever applicable, we 
have endeavored to represent these principles within the Safeguard CTEs 
we discuss. We have also attempted to reflect principles underlying the 
HIT Policy Committee recommendations in the relevant CTEs.
---------------------------------------------------------------------------

    \29\ (2008) ONC. ``Nationwide Privacy and Security Framework for 
Electronic Exchange of Individually Identifiable Health 
Information.'' Available at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov_privacy_security_framework/1173.
---------------------------------------------------------------------------

    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 \30\ and the HIPAA 
Security Rule is scalable and flexible to account for the varying size, 
resources, technology and security risks faced by covered entities.\31\ 
However, given the nature of the services NVEs will be performing, we 
believe that it would be appropriate and justified in the context of 
electronic exchange for NVEs to be held to a more uniform set of 
practices and policies than those that may be adopted to comply with 
the HIPAA Privacy and Security Rules.
---------------------------------------------------------------------------

    \30\ (2000). Final Rule. 65 FR 82462 at 82471. Available at: 
http://www.gpo.gov/fdsys/pkg/FR-2000-12-28/pdf/FR-2000-12-28.pdf.
    \31\ (2003). Final Rule. 68 FR 8335. Available at: http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/securityrulepdf.pdf.
---------------------------------------------------------------------------

     Condition [S-1]: An NVE must comply with sections 164.308, 
164.310, 164.312, and 164.316 of title 45 of the Code of Federal 
Regulations as if it were a covered entity, and must treat all 
implementation specifications included within sections 164.308, 
164.310, and 164.312 as ``required.''
    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: Are there HIPAA Security Rule implementation 
specifications that should not be required of entities that facilitate 
electronic exchange? If so, which ones and why?
    Question 23: Are there other security frameworks or guidance that 
we should consider for this CTE? Should we look to leverage NISTIR 7497 
Security Architecture Design Process for Health Information Exchanges? 
\32\ If so, please also include information on how this framework would 
be validated.
---------------------------------------------------------------------------

    \32\ (2010) NIST. ``Security Architecture Design Process for 
Health Information Exchanges (HIEs).'' Available at: http://csrc.nist.gov/publications/nistir/ir7497/nistir-7497.pdf.
---------------------------------------------------------------------------

     Condition [S-2]: An NVE must only facilitate electronic 
health information exchange for parties it has authenticated and 
authorized, either directly or indirectly.
    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

[[Page 28554]]

available to determine the appropriate authentication requirements NVEs 
would need to satisfy in facilitating electronic exchange.
    Question 24: What is the most appropriate level of assurance that 
an NVE should look to achieve in directly authenticating and 
authorizing a party for which it facilitates electronic exchange?
    Question 25: Would an indirect approach to satisfy this CTE reduce 
the potential trust that an NVE could provide? More specifically, 
should we consider proposing specific requirements that would need to 
be met in order for indirect authentication and authorization processes 
to be implemented consistently across NVEs?
    Question 26: With respect to this CTE as well as others 
(particularly the Safeguards CTEs), should we consider applying the 
``flow down'' concept in more cases? That is, should we impose 
requirements on NVEs to enforce upon the parties for which they 
facilitate electronic exchange, to ensure greater consistency and/or 
compliance with the requirements specified in some CTEs?
     Condition [S-3]: An NVE must ensure that individuals are 
provided with a meaningful choice regarding whether their IIHI may be 
exchanged by the NVE.
    In considering the recommendations that we received from the HIT 
Policy Committee,\33\ we believe that individuals should be able to 
exercise meaningful choice with respect to how their electronic health 
information is exchanged. The HIT Policy Committee explained that 
``meaningful choice'' could be either an opt-in or opt-out model,\34\ 
or more granular consents so long as individuals or their legal 
designees are adequately and clearly informed about how and why their 
information will be exchanged, in advance of making a decision whether 
to participate in electronic exchange. The HIT Policy Committee also 
stated that the process of providing meaningful choice should include 
communicating to an individual the following: 1) that choice is not a 
condition of receiving medical treatment; 2) that the choice will be 
commensurate with the circumstances for why IIHI is being exchanged; 3) 
that the choice is consistent with reasonable patient privacy, health, 
and safety expectations; and 4) that the choice is revocable--that is 
it can be retracted.
---------------------------------------------------------------------------

    \33\ (2010). The complete set of recommendations can be viewed 
on the ONC Web site at: http://healthit.hhs.gov/portal/server.pt/
gateway/PTARGS--0--0--6011--1815--17825--43/wci-pubcontent/
publish/onc/public--communities/--content/files/hitpc--transmittal--
p--s--tt--9--1--10.pdf.
    \34\ In an opt- out model, by default, all or some predefined 
set of data is automatically eligible for exchange, with a provision 
that patients must be given the opportunity to request that their 
data not be eligible for exchange. In contrast, in an opt-in model, 
by default, no patient data is automatically eligible for exchange. 
Patients wishing to make all, or a pre-defined set, of their 
information available must actively express their desire to make 
their data eligible for exchange.
---------------------------------------------------------------------------

    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,\35\ what exceptions to the 
provision of meaningful choice would be prudent. We are considering the 
following three situational exceptions within this specific context: 
(1) When the NVE is engaging in the exchange of IIHI for purposes of 
medical treatment; (2) when information exchange is mandatorily 
required under law; or (3) the NVE is acting solely as a conduit and 
not accessing or using IIHI beyond what is required to encrypt and 
route it to its intended destination. For example, if we were to adopt 
a CTE that excluded those purposes it would mean that no patient choice 
would be required when one provider purposefully elects to 
electronically exchange health information directly with another 
provider for treatment purposes (e.g., sending a referral to a specific 
provider, transmitting a prescription) beyond what is required in 
current law or what has been customary practice. The HIT Policy 
Committee has yet to assess and provide recommendations to the National 
Coordinator on the circumstances under which meaningful choice should 
be required for other electronic exchange purposes. We note, however, 
that the HIPAA Privacy Rule sets a baseline that requires express 
authorization (an opt-in approach) for certain purposes, such as 
marketing with very limited exceptions.
---------------------------------------------------------------------------

    \35\ An NVE must be able to facilitate secure electronic health 
information exchange in two circumstances: (1) When the sender and 
receiver are known; and (2) when the exchange occurs at the 
patient's direction.
---------------------------------------------------------------------------

    Question 27: In accommodating various meaningful choice approaches 
(e.g., opt-in, opt-out, or some combination of the two), what would be 
the operational challenges for each approach? What types of criteria 
could we use for validating meaningful choice under each approach? 
Considering some States have already established certain ``choice'' 
policies, how could we ensure consistency in implementing this CTE?
    Question 28: Under what circumstances and in what manner should 
individual choice be required for other electronic exchange purposes?
    Question 29: Should an additional ``meaningful choice'' Safeguards 
CTE be considered to address electronic exchange scenarios (e.g., 
distributed query) that do not take place following Interoperability 
CTE I-1?
    Question 30: The process of giving patients a meaningful choice may 
be delegated to providers or other users of NVE services (as opposed to 
the patient receiving the choice from the NVE directly). In such 
instances, how would the provision of meaningful choice be validated?
     Condition [S-4]: An NVE must only exchange encrypted IIHI.
    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.\36\
---------------------------------------------------------------------------

    \36\ (2009). Interim Final Rule. 74 FR 42740. Available at: 
http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html.
---------------------------------------------------------------------------

    Question 31: Should there be exceptions to this CTE? If so, please 
describe these exceptions.
     Condition [S-5]: An NVE must make publicly available a 
notice of its data practices describing why IIHI is collected, how it 
is used, and to whom and for what reason it is disclosed.
    Under the HIPAA Privacy Rule (45 CFR 164.520), individuals have the 
right

[[Page 28555]]

to adequate notice of the uses and disclosures of their protected 
health information, a right which a covered entity fulfills by 
furnishing a notice of privacy practices (NPP). Generally speaking, the 
HIPAA Privacy Rule NPP must include a description of the types of uses 
and disclosures a HIPAA covered entity is permitted to make for 
treatment, payment, and health care operations, as well as a 
description of other uses and disclosures which are permitted without 
the individuals' written authorization.
    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: Are there specific uses or actions about which we 
should consider explicitly requiring an NVE to be transparent?
    Question 33: Would an NVE be able to accurately disclose all of the 
activities it may need to include in its notice? Should some type of 
summarization be permitted?
    Question 34: What is the anticipated cost and administrative burden 
for providing such notice?
    Question 35: Should this CTE require that an NVE disclose its 
activities related to de-identified and aggregated data?
    Question 36: Should this CTE require that an NVE just post its 
notice on a Web site or should it be required to broadly disseminate 
the notice to the health care providers and others to which it provides 
electronic exchange services?
     Condition [S-6]: An NVE must not use or disclose de-
identified health information to which it has access for any commercial 
purpose.
    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.\37\ We also believe that such a prohibition 
would increase providers' trust in exchanging their data through an 
NVE.
---------------------------------------------------------------------------

    \37\ We believe that the risks for re-identification are 
somewhat exaggerated, but recognize that public concerns about this 
issue may undermine trust and impede the development of the 
standards, services, and policies that define the nationwide health 
information network.
---------------------------------------------------------------------------

    Question 37: What impact, if any, would this CTE have on various 
evolving business models? Would the additional trust gained from this 
CTE outweigh the potential impact on these models?
    Question 38: On what other entities would this have an effect?
     Condition [S-7]: An NVE must operate its services with 
high availability.
    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: What standard of availability, if any, is appropriate?
     Condition [S-8]: If an NVE assembles or aggregates health 
information that results in a unique set of IIHI, then it must provide 
individuals with electronic access to their unique set of IIHI.
    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

[[Page 28556]]

set of IIHI. This CTE would require that an individual have access to 
this unique set of IIHI if he or she is unable to access the same set 
of information through some other singular channel (e.g., by making a 
standard HIPAA access request to a single health care provider).
    Question 40: What further parameters, if any, should be placed on 
what constitutes a ``unique set of IIHI''?
     Condition [S-9]: If an NVE assembles or aggregates health 
information which results in a unique set of IIHI, then it must provide 
individuals with the right to request a correction and/or annotation to 
this unique set of IIHI.
    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: If an NVE were to honor an individual's request for a 
correction to the unique set of IIHI that it maintains, what impact 
could such a correction have if the corrected information was 
accessible by health care providers and not used solely for the NVE's 
own business processes?
    Question 42: Are there any circumstances where an NVE should not be 
required to provide individuals with the ability to correct their IIHI?
     Condition [S-10]: An NVE must have the means to verify 
that a provider requesting an individual's health information through a 
query and response model has or is in the process of establishing a 
treatment relationship with that individual.
    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.\38\ More specifically, the HIPAA 
Privacy Rule permits providers to request and disclose information 
about a patient ``to carry out treatment'' without qualifying that the 
information must be for the treatment of that particular patient. This 
means that providers who may participate in health information exchange 
through an NVE based on the query and response model are permitted by 
HIPAA to disclose an individual's information for treatment purposes, 
and to have the NVE make the disclosure on their behalf, even if the 
recipient is treating a patient that is not the subject of the record.
---------------------------------------------------------------------------

    \38\ A covered entity requesting protected health information 
from another covered entity must adhere to the minimum necessary 
standard with respect to what information is requested; however, 
disclosures to or requests by a health care provider for treatment 
purposes are not subject to these minimum necessary restrictions. 45 
CFR 164.502(b).
---------------------------------------------------------------------------

    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.\39\ If the provider had any treatment purpose 
for such a query, even if she lacked an actual treatment relationship 
with each patient whose record she received, there would not be a 
violation of the HIPAA Privacy Rule. We believe that in order to ensure 
trust in the query and response model, that: (1) As a business 
practice, the NVE should restrict access to patient data for treatment 
purposes to providers who have or are in the process of establishing a 
treatment relationship with the patient; and (2) that as a safeguard 
CTE, the NVE be required to have mechanisms in place to verify that 
such a relationship exists.
---------------------------------------------------------------------------

    \39\ The President's Council of Advisors on Science and 
Technology report, Realizing the Full Potential of Health 
Information Technology to Improve Healthcare for Americans: The Path 
Forward, (Dec. 2010), for example, proposes a Google-like search 
engine for health information that would facilitate such queries.
---------------------------------------------------------------------------

    Question 43: What method or methods would be least burdensome but 
still appropriate for verifying a treatment relationship?
    Question 44: Are there circumstances where a provider should be 
allowed access through the NVE to the health information of one or more 
individuals with whom it does not have a treatment relationship for the 
purpose of treating one of its patients?
2. Interoperability CTEs
    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.
    Condition [I-1]: An NVE must be able to facilitate secure 
electronic health information exchange in two circumstances: (1) When 
the sender and receiver are known; and (2) when the exchange occurs at 
the patient's direction.
    This Interoperability CTE would address ``planned'' electronic 
exchange scenarios when the sender and receiver are known (e.g., public 
health reporting, transitions of care) and scenarios when the exchange 
occurs at the patient's direction or with the patient's knowledge. An 
NVE seeking validation to facilitate planned electronic exchange would 
need to be able to do so according to secure specifications. We 
anticipate that this first governance rulemaking would focus solely on 
the specifications NVEs would need to be able to use to transport 
electronic health information for planned electronic exchange and would 
not focus on content exchange or vocabulary standards which we have 
largely addressed through our regulations related to EHR technology 
certification.
    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.40 41
---------------------------------------------------------------------------

    \40\ The specification document can be viewed on The Direct 
Project Web site at: http://wiki.directproject.org/Documentation+Library.
    \41\ The specification document can be viewed on the S&I 
Framework Web site at: http://modularspecs.siframework.org/NwHIN+SOAP+Based+Secure+Transport+Artifacts.
---------------------------------------------------------------------------

    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,

[[Page 28557]]

interested entities who facilitate planned electronic exchange to 
satisfy this CTE.
    Question 45: What types of transport methods/standards should NVEs 
be able to support? Should they support both types of transport 
methods/standards (i.e., SMTP and SOAP), or should they only have to 
meet one of the two as well as have a way to translate (e.g., XDR/XDM)?
    Question 46: If a secure ``RESTful'' transport specification is 
developed during the course of this rulemaking, should we also propose 
it as a way of demonstrating compliance with this CTE?
     Condition [I-2]: An NVE must follow required standards for 
establishing and discovering digital certificates.
    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: Are the technical specifications (i.e., Domain Name 
System (DNS) and the Lightweight Directory Access Protocol (LDAP)) 
appropriate and sufficient for enabling easy location of organizational 
certificates? Are there other specifications that we should also 
consider?
    Question 48: Should this CTE require all participants engaged in 
planned electronic exchange to obtain an organizational (or group) 
digital certificate consistent with the policies of the Federal Bridge? 
\42\
---------------------------------------------------------------------------

    \42\ Additional information on the Federal Bridge can be viewed 
at: http://www.idmanagement.gov/pages.cfm/page/Federal-PKI.
---------------------------------------------------------------------------

     Condition [I-3]: An NVE must have the ability to verify 
and match the subject of a message, including the ability to locate a 
potential source of available information for a specific subject.
    The intent of this CTE is to provide guidance for NVEs to verify 
and match message subjects (i.e., patients) using a record locater 
services, master patient index, or another approach. In February 2011, 
the Privacy and Security Tiger team issued a set of recommendations to 
the HIT Policy Committee regarding patient matching. The 
recommendations centered on standardizing demographic data fields, 
evaluating matching consistency, accountability, developing and 
disseminating best practices, and supporting the role of the individual 
patient. Subsequently, the HIT Standards Committee formed the Patient 
Matching Power Team to further explore these recommendations. The 
Patient Matching Power Team focused specifically on the use case of 
near time, direct patient care.\43\
---------------------------------------------------------------------------

    \43\ The complete set of recommendations can be viewed on the 
ONC Web site at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__standards_recommendations/1818.
---------------------------------------------------------------------------

    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: Should we adopt a CTE that requires NVEs to employ 
matching algorithms that meet a specific accuracy level or a CTE that 
limits false positives to certain minimum ratio? What should the 
required levels be?
    Question 50: What core data elements should be included for patient 
matching queries?
    Question 51: What standards should we consider for patient matching 
queries?
3. Business Practice CTEs
    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.
     Condition [BP-1]: An NVE must send and receive any planned 
electronic exchange message from another NVE without imposing financial 
preconditions on any other NVE.
    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

[[Page 28558]]

health information on behalf of its customer (e.g., a doctor). We 
believe this CTE would be especially relevant in preventing instances 
where an NVE with a significant share of the market would try to 
leverage their market dominance to impose an economic ``rent'' on other 
NVEs (e.g., excessive fees), resulting in market distortions. It would 
also prevent an NVE from making it difficult for their customers--those 
using the services offered by the NVE--to conduct electronic exchange 
with another NVE.
    Question 52: Should this CTE be limited to only preventing one NVE 
from imposing a financial precondition on another NVE (such as fees), 
or should it be broader to cover other instances in which an NVE could 
create an inequitable electronic exchange environment?
    Question 53: Should this CTE (or another CTE) address the fees an 
NVE could charge its customers to facilitate electronic exchange or 
should this be left to the market to determine?
    Question 54: Under what circumstances, if any, should an NVE be 
permitted to impose requirements on other NVEs?
     Condition [BP-2]: An NVE must provide open access to the 
directory services it provides to enable planned electronic exchange.
    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.
     Condition [BP-3]: An NVE must report on users and 
transaction volume for validated services.
    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: What data would be most useful to be collected? How 
should it be made available to the public? Should NVEs be required to 
report on the transaction volume by end user type (e.g., provider, lab, 
public health, patient, etc)?

E. Request for Additional CTEs

    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.

------------------------------------------------------------------------
               CTE Category                              CTE
------------------------------------------------------------------------
Safeguards................................  [S-1]: An NVE must comply
                                             with sections 164.308,
                                             164.310, 164.312, and
                                             164.316 of title 45 of the
                                             Code of Federal Regulations
                                             as if it were a covered
                                             entity, and must treat all
                                             implementation
                                             specifications included
                                             within sections 164.308,
                                             164.310, and 164.312 as
                                             ``required.''
Safeguards................................  [S-2]: An NVE must only
                                             facilitate electronic
                                             health information exchange
                                             for parties it has
                                             authenticated and
                                             authorized, either directly
                                             or indirectly.
Safeguards................................  [S-3]: An NVE must ensure
                                             that individuals are
                                             provided with a meaningful
                                             choice regarding whether
                                             their IIHI may be exchanged
                                             by the NVE.
Safeguards................................  [S-4]: An NVE must only
                                             exchange encrypted IIHI.
Safeguards................................  [S-5]: An NVE must make
                                             publicly available a notice
                                             of its data practices
                                             describing why IIHI is
                                             collected, how it is used,
                                             and to whom and for what
                                             reason it is disclosed.
Safeguards................................  [S-6]: An NVE must not use
                                             or disclose de-identified
                                             health information to which
                                             it has access for any
                                             commercial purpose.
Safeguards................................  [S-7]: An NVE must operate
                                             its services with high
                                             availability.
Safeguards................................  [S-8]: If an NVE assembles
                                             or aggregates health
                                             information that results in
                                             a unique set of IIHI, then
                                             it must provide individuals
                                             with electronic access to
                                             their unique set of IIHI.
Safeguards................................  [S-9]: If an NVE assembles
                                             or aggregates health
                                             information which results
                                             in a unique set of IIHI,
                                             then it must provide
                                             individuals with the right
                                             to request a correction and/
                                             or annotation to this
                                             unique set of IIHI.
Safeguards................................  [S-10]: An NVE must have the
                                             means to verify that a
                                             provider requesting an
                                             individual's health
                                             information through a query
                                             and response model has or
                                             is in the process of
                                             establishing a treatment
                                             relationship with that
                                             individual.
Interoperability..........................  [I-1]: An NVE must be able
                                             to facilitate secure
                                             electronic health
                                             information exchange in two
                                             circumstances: 1) when the
                                             sender and receiver are
                                             known; and 2) when the
                                             exchange occurs at the
                                             patient's direction.
Interoperability..........................  [I-2]: An NVE must follow
                                             required standards for
                                             establishing and
                                             discovering digital
                                             certificates.
Interoperability..........................  [I-3]: An NVE must have the
                                             ability to verify and match
                                             the subject of a message,
                                             including the ability to
                                             locate a potential source
                                             of available information
                                             for a specific subject.
Business Practices........................  [BP-1]: An NVE must send and
                                             receive any planned
                                             electronic exchange message
                                             from another NVE without
                                             imposing financial
                                             preconditions on any other
                                             NVE.
Business Practices........................  [BP-2]: An NVE must provide
                                             open access to the
                                             directory services it
                                             provides to enable planned
                                             electronic exchange.
Business Practices........................  [BP-3]: An NVE must report
                                             on users and transaction
                                             volume for validated
                                             services.
------------------------------------------------------------------------

    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.\44\ These specifications focus on a range of 
different electronic exchange activities, including

[[Page 28559]]

specifications for: ``Patient Discovery;'' ``Query for Documents;'' 
``Retrieve Documents;'' ``Authorization Framework;'' ``Web Services 
Registry;'' ``Access Consent Policies;'' and other such specifications 
with a yet to be determined effective date.
---------------------------------------------------------------------------

    \44\ The Exchange specifications can be viewed on the ONC Web 
site at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__nhin_resources/1194.
---------------------------------------------------------------------------

    Question 56: Which CTEs would you revise or delete and why? Are 
there other CTEs not listed here that we should also consider?
    Question 57: Should one or more of the performance and service 
specifications implemented by the participants in the Exchange be 
included in our proposed set of CTEs? If so, please indicate which 
one(s) and provide your reasons for including them in one or more CTEs. 
If not, please indicate which one(s) and your reasons (including any 
technical or policy challenges you believe exist) for not including 
them in one or more CTEs.
    Question 58: In the notice of proposed rulemaking (NPRM) we intend 
to subsequently issue, should the above CTEs as well as any others we 
consider for the NPRM be packaged together for the purposes of 
validation? In other words, would it make sense to allow for validation 
to different bundles of safeguard, interoperability, and business 
practice CTEs for different electronic exchange circumstances?
    Question 59: Should we consider including safe harbors for certain 
CTEs? If so, which CTEs and what should the safe harbor(s) be?

F. CTE Processes and Standards and Implementation Specification 
Classifications

1. CTE Life Cycle
    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: What process should we use to update CTEs?
    Question 61: Should we expressly permit validation bodies to 
provide for validation to pilot CTEs?
    Question 62: Should we consider a process outside of our advisory 
committees through which the identification and development to frame 
new CTEs could be done?
2. Interoperability Conditions for Trusted Exchange--Technical 
Standards and Implementation Specifications Classification Process
    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.\45\ 
This process would be informed by the priorities set by ONC based in 
part on recommendations from the HIT Policy and Standards Committees 
through an annual review and assessment process.
---------------------------------------------------------------------------

    \45\ Examples of technical standards include SMTP, S/MIME and 
X.509 which form one of the transport specifications we identify for 
satisfying CTE I-1.
---------------------------------------------------------------------------

    Through this process, technical standards and implementation 
specifications could be assigned to one of three classifications:
     ``Emerging''--This classification would refer to the 
technical standards and implementation specifications that still 
require additional specification and vetting by the standards 
development community, have not been broadly tested, have no or low 
adoption, and have only been implemented within a local or controlled 
setting.
     ``Pilot''--This classification would refer to the 
technical standards and implementation specifications that have reached 
a level of specification maturity and adoption by different entities 
such that some entities are using them to exchange health information 
either in a test mode or in a limited production mode.
     ``National''--This classification would refer to the 
technical standards and implementation that have reached a high-level 
of specification maturity and adoption by different entities such that 
most entities are using or are readily able to adopt and use them to 
exchange health information to conduct business. These technical 
standards would also be candidates for inclusion in applicable 
regulations, such as being referenced in an Interoperability CTE.
    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: What would be the best way(s) ONC could help 
facilitate the pilot testing and learning necessary for implementing 
technical standards and implementation specifications categorized as 
Emerging or Pilot?
    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

[[Page 28560]]

characteristics should be put on a path toward national adoption.
[GRAPHIC] [TIFF OMITTED] TP15MY12.034

    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: Would this approach for classifying technical 
standards and implementation specification be effective for updating 
and refreshing Interoperability CTEs?
    Question 65: What types of criteria could be used for categorizing 
standards and implementation specifications for Interoperability CTEs? 
We would prefer criteria that are objective and quantifiable and 
include some type of metric.

G. Economic Impact

    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: We encourage comment and citations to publicly 
available data regarding the following:
    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.

    Dated: May 10, 2012.
David S. Muntz,
Principal Deputy National Coordinator, Office of the National 
Coordinator for Health IT.
[FR Doc. 2012-11775 Filed 5-11-12; 11:15 am]
BILLING CODE 4150-45-P