Metadata Standards To Support Nationwide Electronic Health Information Exchange, 48769-48776 [2011-20219]

Agencies

• Office of the Secretary
• DEPARTMENT OF HEALTH AND HUMAN SERVICES

[Federal Register Volume 76, Number 153 (Tuesday, August 9, 2011)]
[Proposed Rules]
[Pages 48769-48776]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2011-20219]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991-AB78


Metadata Standards To Support Nationwide Electronic Health 
Information Exchange

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

ACTION: Advance notice of proposed rulemaking.

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

SUMMARY: Through this advance notice of proposed rulemaking (ANPRM), 
the Office of the National Coordination for Health Information 
Technology (ONC) is soliciting public comments on metadata standards to 
support nationwide electronic health information exchange. We are 
specifically interested in public comments on the following categories 
of metadata recommended by both the HIT Policy Committee and HIT 
Standards Committee: patient identity; provenance; and privacy. We also 
request public comments on any additional metadata categories, metadata 
elements, or metadata syntax that should be considered. The immediate 
scope of this ANPRM is the association of metadata with summary care 
records. More specifically, in the scenario where a patient obtains a 
summary care record from a health care provider's electronic health 
record technology or requests for it to be transmitted to their 
personal health record. Public comment, however, is also welcome on the 
use of metadata relative to other electronic health information 
contexts.

DATES: To be assured consideration, written comments must be received 
at one of the addresses provided below, no later than 5 p.m. on 
September 23, 2011. Similarly, electronic comments must be received by 
Midnight Eastern Time on September 23, 2011 as the Federal Docket 
Management System will not accept comments after this time.

ADDRESSES: Because of staff and resource limitations, we cannot accept 
comments by facsimile (FAX) transmission. You may submit comments, 
identified by RIN 0991- AB78, by any of the following methods (please 
do not submit duplicate comments).
     Federal eRulemaking Portal: Follow the instructions for 
submitting comments. Attachments should be in Microsoft Word or Excel, 
Adobe PDF; however, we prefer Microsoft Word. https://www.regulations.gov.
     Regular, Express, or Overnight Mail: Department of Health 
and Human Services, Office of the National Coordinator for Health 
Information Technology, Attention: Steven Posnack, 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: Steven 
Posnack, 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

[[Page 48770]]

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 https://www.regulations.gov.
    Docket: For access to the docket to read background documents or 
comments received, go to https://www.regulations.gov or U.S. 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

ANPRM Advance Notice of Proposed Rulemaking
ASTM American Society for Testing and Materials
ARRA American Recovery and Reinvestment Act of 2009
BPPC Basic Patient Privacy Consents
CCR Continuity of Care Record
CDA R2 PCD Clinical Document Architecture Release 2: Patient Consent 
Directives
CDC Centers for Disease Control and Prevention
CDISC Clinical Data Interchange Standards Consortium
CFR Code of Federal Regulations
CMS Centers for Medicare & Medicaid Services
EHR Electronic Health Record
EPAL Enterprise Privacy Authorization Language
EO Executive Order
HIEs Health Information Exchanges
HHS Department of Health and Human Services
HL7 CDA R2 Health Level 7 Clinical Document Architecture Release 2
HL7 V2 Health Level 7 Version 2
HIT Health Information Technology
HITECH Act Health Information Technology for Economic and Clinical 
Health Act
ICD-9 International Classification of Diseases, 9th Revision
ICD-10 International Classification of Diseases, 10th Revision
IHE Integrating the Healthcare Enterprise
IHE XDS Integrating the Healthcare Enterprise Cross Enterprise 
Document Sharing
LOINC Logical Observation Identifiers Names and Codes
NIEM National Information Exchange Model
OID Object Identifier
OMB Office of Management and Budget
OSTP Office of Science and Technology Policy
ONC Office of the National Coordinator for Health Information 
Technology
P3P Platform for Privacy Preferences
PCAST President's Council of Advisors on Science and Technology
PHSA Public Health Service Act
RFI Request for Information
TDE Tagged Data Element
UEL Universal Exchange Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
UUIDs Universally Unique Identifiers
XML eXtensible Markup Language

Table of Contents

I. Background
    A. Legislative History
    B. Regulatory History
    1. Initial Set of Standards, Implementation Specifications, and 
Certification Criteria for Electronic Health Record Technology; 
Interim Final Rule and Final Rule
    2. Revisions to Initial Set of Standards, Implementation 
Specifications, and Certification Criteria for EHR Technology; 
Interim Final Rule
    C. The President's Council of Advisors on Science and Technology 
(PCAST) Report
    1. Request for Information on PCAST Report Recommndations 
Affecting ONC Activities
    2. The PCAST Workgroup
    D. Analysis of Metadata Standards
    1. ONC-Commissioned Analysis
    2. HIT Standards Committee Analysis and Recommendations
II. Metadata Standards Under Consideration
    A. Metadata Standards Discussed and Specific Questions for 
Public Comment
    1. Patient Identity Metadata Standards
    2. Provenance Metadata Standards
    3. Privacy Metadata Standards
    B. Metadata Example
III. Additional Questions

I. Background

A. Legislative History

    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 
health information technology (HIT) and the electronic exchange of 
health information. 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) of the PHSA states that ``[t]he HIT 
Standards Committee shall 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.''
    Section 3001(c)(1)(A) of the PHSA, under ``Duties of the 
National Coordinator,'' states that the National Coordinator shall 
``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.''
    Section 3004 of the PHSA identifies a process for the adoption 
of health IT standards, implementation specifications, and 
certification criteria and authorizes the Secretary of Health and 
Human Services (the Secretary) to adopt such standards, 
implementation specifications, and certification criteria. As 
specified in section 3004(a)(1), the Secretary is required, in 
consultation with representatives of other relevant Federal 
agencies, to jointly review standards, implementation 
specifications, and certification criteria endorsed by the National 
Coordinator for Health Information Technology (the National 
Coordinator) under section 3001(c) and subsequently determine 
whether to propose the adoption of any grouping of such standards, 
implementation specifications, or certification criteria. Section 
3004(b)(1) of the PHSA requires the Secretary to adopt an initial 
set of standards, implementation specifications, and certification 
criteria for the areas required for consideration under section 
3002(b)(2)(B) by December 31, 2009 and permits the Secretary to 
adopt the initial set through an interim final rule. Section 
3004(b)(3) of the PHSA directs the Secretary to ``adopt additional 
standards, implementation specifications, and certification criteria 
as necessary and consistent with the schedule'' developed by the HIT 
Standards Committee under section 3003(b)(3) of the PHSA \1\ for the 
assessment of policy recommendations developed by the HIT Policy 
Committee.
---------------------------------------------------------------------------

    \1\ PHSA section 3004(b)(3) incorrectly references section 
3003(b)(2) when referring to the schedule developed by the HIT 
Standards Committee. We have used the correct citation: 3003(b)(3).

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

[[Page 48771]]

B. Regulatory History

1. Initial Set of Standards, Implementation Specifications, and 
Certification Criteria for Electronic Health Record Technology; Interim 
Final Rule and Final Rule

    On January 13, 2010, the Department of Health and Human Services 
(HHS) published in the Federal Register an interim final rule with a 
request for comment, which adopted an initial set of standards, 
implementation specifications, and certification criteria (75 FR 
2014). The certification criteria adopted in that interim final rule 
established the required capabilities and specified the related 
standards and implementation specifications that certified 
electronic health record (EHR) technology would need to include to, 
at a minimum, support the achievement of meaningful use Stage 1 as 
proposed by the Centers for Medicare & Medicaid Services (CMS) for 
eligible professionals and eligible hospitals under the Medicare and 
Medicaid EHR Incentive Programs. For consistency with other 
regulations, hereafter, references to ``eligible hospitals'' shall 
mean eligible hospitals, critical access hospitals, or both, as 
defined in 42 CFR 495.4.
    On July 28, 2010, HHS published in the Federal Register a final 
rule (75 FR 44590) to complete the Secretary's adoption of the 
initial set of standards, implementation specifications, and 
certification criteria, and to more closely align such standards, 
implementation specifications, and certification criteria with final 
meaningful use Stage 1 objectives and measures (the ``Standards and 
Certification Criteria Final Rule''). Complete EHRs and EHR Modules 
are tested and certified according to adopted certification criteria 
to ensure that they have properly implemented adopted standards and 
implementation specifications and otherwise comply with the adopted 
certification criteria.

2. Revisions to Initial Set of Standards, Implementation 
Specifications, and Certification Criteria for EHR Technology; Interim 
Final Rule

    On October 13, 2010, HHS published in the Federal Register an 
interim final rule (75 FR 62686) with a request for comment to 
remove the implementation specifications related to public health 
surveillance from the adopted standard and certification criterion. 
In response to public comment on the interim final rule published on 
January 13, 2010, we adopted in the Standards and Certification 
Criteria Final Rule the following implementation specifications for 
HL7 2.5.1: Public Health Information Network HL7 Version 2.5 Message 
Structure Specification for National Condition Reporting Final 
Version 1.0 and the Errata and Clarifications National Notification 
Message Structural Specification (45 CFR 170.205(d)(2)). After 
publication of the Standards and Certification Criteria Final Rule, 
various stakeholders and state public health agencies made numerous 
inquiries and expressed concerns about the appropriateness of these 
implementation specifications. Upon further review of the 
implementation specifications and consultation with the Centers for 
Disease Control and Prevention (CDC), we determined that these 
implementation specifications were adopted in error. Therefore, we 
revised 45 CFR 170.205(d)(2) to remove these particular adopted 
implementation specifications and removed from 45 CFR 170.302(l) the 
text ``(and applicable implementation specifications)'' to provide 
additional clarity.

C. The President's Council of Advisors on Science and Technology 
(PCAST) Report

    On December 8, 2010, the President's Council of Advisors on 
Science and Technology (PCAST) released a report entitled 
``Realizing the Full Potential of Health Information Technology to 
Improve Healthcare for Americans: The Path Forward'' (the PCAST 
Report).\2\ PCAST is an advisory group of the nation's leading 
scientists and engineers who directly advise the President and the 
Executive Office of the President. PCAST makes policy 
recommendations in many areas where the understanding of science, 
technology, and innovation is key to strengthening our economy and 
forming policy that works for the American people. PCAST is 
administered by the Office of Science and Technology Policy (OSTP) 
within the Executive Office of the President. Generally speaking, 
the PCAST Report included both a broad vision and specific 
recommendations to accelerate the nation's progress toward 
electronic health information exchange. Many of the PCAST Report's 
recommendations are related to electronic health information 
exchange activities that ONC could directly affect.
---------------------------------------------------------------------------

    \2\ https://www.whitehouse.gov/administration/eop/ostp/pcast
---------------------------------------------------------------------------

1. Request for Information on PCAST Report Recommendations Affecting 
ONC Activities

    On December 10, 2010, the Office of the National Coordinator for 
Health Information Technology (ONC) issued a Request for Information 
(RFI) to seek public comment on the PCAST Report's vision and 
recommendations and how they may be best addressed (75 FR 76986). 
The RFI sought specific feedback on nine questions which are best 
organized according to the following categories:
     The standards, implementation specifications, 
certification criteria, and certification processes for EHR 
technology and other types of HIT that would be required to 
implement some of the PCAST Report's recommendations;
     The current state of information technology solutions 
needed to support the PCAST Report's vision as well as lessons that 
could be learned from other industry implementations;
     The steps that could be taken to best integrate the 
changes envisioned by the PCAST Report into future stages of 
meaningful use; and
     The impact of the PCAST recommendations on ONC programs 
and ongoing activities.
    In total, ONC received 105 timely comments on the RFI from 
stakeholders throughout the health care industry. These comments 
were consolidated into a summary report to inform the deliberations 
of the PCAST Workgroup formed under the HIT Policy Committee 
(discussed below). The following major themes emerged from public 
comments: timelines; the effects on ONC programs; implementation of 
the PCAST recommendations; privacy and security; and standards.
     Timelines. Several commenters supported the PCAST 
recommendations to increase information exchange capacity before 
meaningful use Stage 2. A significant majority of commenters, 
however, were concerned that attempting to fully implement the PCAST 
recommendations in the midst of meaningful use Stages 2 and 3 along 
with other changing standards such as the International 
Classification of Diseases, 9th Revision (ICD-9) transition to 
International Classification of Diseases, 10th Revision (ICD-10) 
could have potential negative effects. Many commenters suggested 
that the recommendations serve to inform a long term strategy rather 
than direct an immediate deviation from already laid groundwork 
created by meaningful use Stage 1 and other ONC electronic health 
information exchange activities.
     Effects on ONC Programs. A majority of commenters 
encouraged ONC to leverage the success of ongoing programs and avoid 
reinventing the wheel in the midst of the Medicare and Medicaid EHR 
Incentive Programs. Many commenters stated that fully implementing 
the PCAST Report's recommendations would require redesigning many of 
the ongoing federal HIT grants and contracts which could impose 
substantial costs to current participants. Some suggested that ONC 
begin with pilots to develop and test PCAST technology solutions 
before moving into broader implementation efforts.
     Implementation of PCAST Recommendations. Commenters 
generally agreed that health information exchanges (HIEs) and the 
electronic exchange of health information should be the focus of 
future stages of meaningful use. Regarding the exchange of 
individual data elements outside of a document structure, many 
agreed with the value of exchanging individual data elements but 
recommended that such a program begin with pilot testing that takes 
into account patient-linking and public trust issues.
     Privacy and Security. Several commenters supported the 
concept of giving patients granular consent as envisioned in the 
PCAST Report. However, many expressed concern that tagging patient 
privacy preferences to the data would lead to a static, rather than 
a dynamic, data control environment which could prevent patients 
from updating their privacy preferences once the data was released. 
The research community largely supported PCAST's concept of creating 
a subset of de-identified data for the purpose of research.
     Standards. Most commenters believed that ONC should 
learn from and leverage existing standards that incorporate metadata 
concepts. Some commenters asserted that ONC should pursue the 
metadata approach outlined in the PCAST Report because current 
standards do not allow for innovation, flexibility, or scalability 
and that today's predominantly document-centric environment would 
not support PCAST's

[[Page 48772]]

vision. Others contended that the PCAST Report's interoperability 
and electronic exchange goals could be met with existing and 
emerging standards.

2. The PCAST Workgroup

    In January 2011, ONC asked the HIT Policy Committee to provide a 
more detailed assessment of the PCAST Report's ONC-related 
recommendations, how implementing the recommendations could affect 
ONC's programs, and potential approaches ONC could pursue to realize 
the vision described in the PCAST Report. To respond to this 
request, the HIT Policy Committee, in conjunction with the HIT 
Standards Committee, formed an interdisciplinary PCAST Workgroup to 
analyze the RFI comments as well as solicit expert testimony through 
a public hearing held in February 2011.
    In April 2011, the HIT Policy Committee transmitted to ONC an 
analysis report that suggested incremental steps for ONC to pursue 
to achieve the vision described in the PCAST Report. As a feasible 
first step, the HIT Policy Committee suggested that ONC focus on 
facilitating the development and adoption of a minimal set of 
standards for metadata that could be ``wrapped around'' or attached 
to a summary care record when a patient seeks to download their 
health information from, for example, a health care provider's 
patient portal or when a patient directs his or her health care 
provider to transmit his or her health information to a personal 
health record (PHR). Generally speaking, the term ``metadata'' is 
often used to mean ``data about data'' or, in other words, ``data 
that provides more information or detail about a piece of data.''
    The HIT Policy Committee suggested that it would be practical to 
include this capability as part of the EHR certification 
requirements to support meaningful use Stage 2 under the Medicare 
and Medicaid EHR Incentive Programs. Moreover, in the context of 
this first ``use case,'' the HIT Policy Committee noted that a 
minimum set of metadata (and accompanying standards) should focus on 
these three categories: patient identity (data elements about a 
patient), provenance (data elements about the source of the clinical 
data), and privacy (data elements about the type(s) and sensitivity 
of clinical data included). Additionally, the HIT Policy Committee 
noted that if these metadata are available, they could potentially 
increase the level of trust that receiving providers would place in 
clinical information that they receive through patient-mediated 
exchange, such as from a PHR, and could enable patients to more 
easily sort and re-share their own health information.

D. Analysis of Metadata Standards

1. ONC-Commissioned Analysis

    In parallel with the work being done by the PCAST Workgroup, ONC 
commissioned an in-depth analysis of several widely implemented 
standards that include metadata. This analysis examined the various 
data elements each standard includes and identified certain 
categories of metadata that could be readily adopted as metadata 
standards. On April 20, 2011, this analysis was presented to the HIT 
Standards Committee, which included metadata options for patient 
identity, provenance, and privacy.
     Patient Identity Metadata: The analysis generally 
described patient identity metadata as the necessary data required 
to uniquely select a patient from a population with a guaranteed 
degree of accuracy. The research also indicated that patient 
identity metadata should include a patient's current full name, 
previous names with associated date ranges (as an optional element), 
date of birth, postal code, and one type of patient identification 
data (ID) along with the origin of that ID. The following standards 
were reviewed and compared relative to how patient identity metadata 
is represented: Health Level 7 Version 2 (HL7 V2) messages; 
Integrating the Healthcare Enterprise Cross Enterprise Document 
Sharing (IHE XDS) Metadata; Health Level 7 Clinical Document 
Architecture Release 2 (HL7 CDA R2); American Society for Testing 
and Materials (ASTM) Continuity of Care Record (CCR); Google CCR; 
and National Information Exchange Model (NIEM).
     Provenance Metadata: The analysis generally described 
provenance metadata as data that provides information on a dataset's 
history, origin, and modifications. Research suggested that 
provenance metadata should include information that describes the 
event that led to the creation of the tagged data as well as other 
associated events that provide causal links to the data. The 
research also indicated that provenance metadata include information 
about when and how the tagged data had been exchanged in the past. 
It emphasized that digital signatures could be used as metadata as a 
way to ensure that the data had not been altered since its creation. 
The report gave comparisons on the NIEM, IHE XDS Metadata, HL7 CDA 
R2, and Clinical Data Interchange Standards Consortium (CDISC) 
standards related to providing the above information on provenance.
     Privacy Metadata: For privacy metadata, the 
commissioned analysis of metadata standards examined what data could 
be used to convey and communicate patient preferences (permissions 
or limits) associated with the sharing of his or her health 
information. The analysis first concluded that it was not feasible 
to include the privacy policy with each tagged data element because 
policy can change over time, and that a pointer to an external 
registry would be most appropriate. Noting that there was not 
sufficient information to determine how such privacy policy 
registries would be implemented, the research indicated that privacy 
metadata related to the underlying contents (i.e., what kind of 
information is within a document or message) and its sensitivity 
(i.e., by whom, and what the recipient(s) of the data is/may be 
obligated or prevented from doing after accessing the data) would be 
the most useful to include in an initial set of metadata. The 
research compared the ability of Platform for Privacy Preferences 
(P3P), Enterprise Privacy Authorization Language (EPAL), Basic 
Patient Privacy Consents (BPPC), IHE XDS, and Clinical Document 
Architecture Release 2: Patient Consent Directives (CDA R2 PCD) 
metadata standards to convey the above information.

2. HIT Standards Committee Analysis and Recommendations

    In April 2011, after the receipt of the ONC-commissioned 
analysis on metadata standards, the HIT Standards Committee formed a 
``metadata power team'' to further consider this analysis in order 
to identify metadata standards that would be appropriate for 
electronic health information exchange. On May 18, 2011, after a 
series of public meetings, the metadata power team presented to the 
HIT Standards Committee their review of the metadata elements that 
would be best to consider for patient identity and provenance. On 
May 25, 2011, the metadata power team held another meeting which 
focused on the analysis of privacy metadata elements.
    On June 22, 2011, the metadata power team submitted its complete 
analysis and a set of recommendations to the HIT Standards Committee 
on the data elements that should be included as part of metadata 
standards for patient identity, provenance, and privacy. The HIT 
Standards Committee discussed and subsequently approved the metadata 
power team's findings. The HIT Standards Committee submitted its 
recommendations on metadata elements and standards to the National 
Coordinator and expressed its expectation that ONC would conduct 
further testing and evaluation prior to proposing these standards 
for adoption through rulemaking.
    Upon receipt of the HIT Standards Committee's metadata standards 
recommendations, the National Coordinator followed the process 
outlined in the sections 3001(c)(1)(A) and (B) of the PHSA. These 
provisions require the National Coordinator to ``(A) 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 
under section 3004; [and] (B) make such determinations under 
subparagraph (A), and report to the Secretary such determinations, 
not later than 45 days after the date the recommendation is received 
by the Coordinator * * *''
    The National Coordinator endorsed the HIT Standards Committee 
recommendations on metadata standards and reported this 
determination to the Secretary for consideration under section 
3004(a) of the PHSA. Per section 3004(a)(2), if the Secretary 
determines ``to propose adoption of any grouping of such standards, 
implementation specifications, or certification criteria, the 
Secretary shall, by regulation under section 553 of title 5, United 
States Code, determine whether or not to adopt such grouping of 
standards, implementation specifications, or certification 
criteria.'' In accordance with section 3004(a)(3), the Secretary 
must also provide for publication in the Federal Register all 
determinations made by the Secretary under this provision. This 
ANPRM constitutes publication of the Secretary's determination.

[[Page 48773]]

II. Metadata Standards Under Consideration

    Section 3001 of the HITECH Act establishes ONC by statute and 
requires, under section 3001(b), the National Coordinator to 
``perform the 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 * * *'' Since the HITECH Act's enactment in February 
2009, ONC has developed a portfolio of initiatives to foster a 
nationwide health information technology infrastructure. The PCAST 
Report, published in December 2010, built on our progress to date 
and complemented our existing initiatives. It expressed a vision, 
with associated policy goals, that focused on key challenges ONC 
could undertake to accelerate its efforts in several electronic 
health information exchange areas. One such area, a cornerstone of 
the PCAST Report's vision, was to increase the health care 
industry's ability to understand and parse the health care data 
under its stewardship at a more granular level. The PCAST Report 
noted that the development of metadata standards was a critical 
first step to facilitating more granular understanding of data and 
to establishing a ``universal exchange language (UEL).'' The PCAST 
Report described the UEL as, ``some kind of extensible markup 
language (an XML variant, for example) capable of exchanging data 
from an unspecified number of (not necessarily harmonized) semantic 
realms. Such languages are structured as individual data elements, 
together with metadata that provide an annotation for each data 
element.''
    We believe that the use of metadata holds great promise and the 
adoption of metadata standards can help rapidly advance electronic 
health information exchange across a variety of different exchange 
architectures. The purpose of this ANPRM is to seek broad public 
comment on the metadata standards we are considering proposing for 
adoption in the next notice of proposed rulemaking with regard to 
the standards, implementation specifications, and certification 
criteria intended to support meaningful use Stage 2. We are 
considering whether to propose, as a requirement for certification, 
that EHR technology be capable of applying the metadata standards in 
the context of the use case selected by the HIT Policy Committee 
(i.e., when a patient downloads a summary care record from a health 
care provider's EHR technology or requests for it to be transmitted 
to their PHR). For example, if a patient seeks to obtain an 
electronic copy of her health information, her doctor's EHR 
technology would have to be capable of creating a summary care 
record and subsequently assigning metadata to the summary care 
record before the patient receives it. From an EHR technology 
developer's perspective, we believe this approach would be the least 
difficult to implement in support of meaningful use Stage 2. 
However, generally speaking, we believe this capability may also be 
able to be applied to other directed transfers of summary care 
records (e.g., as part of requirements concerning transitions of 
care). Additionally, looking prospectively, once EHR technology is 
capable of applying metadata, we believe that the health care 
industry could gradually develop innovative ways to repurpose this 
general capability to create more specialized extensions to meet 
future specific policy and organizational objectives. For instance, 
the EHR technology's capability to assign metadata to documents or 
more granular data elements could be used within an organization to 
appropriately filter data prior to making a disclosure or to process 
information more efficiently for quality improvement and 
measurement. In addition to the specific metadata standards 
discussed below, we also request public comments on any other 
metadata categories, metadata elements, or metadata syntax that we 
should consider.
    Consistent with the recommendations of the HIT Standards 
Committee, ONC is interested in learning about and requests public 
comment on any real-life testing or use of these or other metadata 
standards relating to patient identity, provenance, or privacy. ONC 
also intends to seek pilot testing of these metadata standards to 
gain insights into any implementation-level challenges that may 
exist.

A. Metadata Standards Discussed and Specific Questions for Public 
Comment

    This section discusses the metadata standards we are considering 
for each of the three categories (patient identity, provenance, and 
privacy) as recommended by the HIT Standards Committee and includes 
specific questions for the public's consideration. Consistent with 
the recommendations of the HIT Standards Committee, we are 
considering proposing that the metadata would need to be expressed 
according to the requirements in the HL7 CDA R2 header (section 4.2 
of HL7 CDA R2). We are also considering whether to propose the 
adoption of additional metadata elements for certain information 
that is not currently required as part of the HL7 CDA R2 header. The 
HIT Standards Committee recommended the use of the HL7 CDA R2 header 
based on its belief that the HL7 CDA R2's XML format for describing 
generic clinical documents would best support the implementation of 
its recommendations. It specifically noted that among its many 
benefits the HL7 CDA R2 could best accommodate the international 
representation of names and could potentially support additional 
information if desired. The HIT Standards Committee first 
recommended the use of the HL7 CDA R2 header for patient identity 
metadata. Subsequently, it acknowledged and determined that even 
though other standards could support the metadata elements under 
consideration in the provenance and privacy categories that the use 
of the HL7 CDA R2 header for these two categories would complement 
its already recommended use for patient identity metadata. Its 
overall rationale for the selection and recommendation of the HL7 
CDA R2 header was that it provides wide coverage across metadata 
elements and working from a single standard would make 
implementation easier.
    At the end of this section, we provide a complete example of how 
the metadata could be expressed. We request public comment on the 
metadata standards discussed below and in response to the specific 
questions listed below.

1. Patient Identity Metadata Standards

    We are considering the following standard set of patient 
identity metadata recommended by HIT Standards Committee. This 
standard set would include the following data elements expressed 
according to the requirements explained below.
     Name: Would include the patient's name prefix (e.g., 
Mr. Ms. Dr.), given names (e.g., first and middle names/middle 
initial), family names, and name suffix. Inclusion of ``other name'' 
components, such as patient's maiden name, previous names, or 
mother's name for newborns would be optional.
     Date of birth: Would include the patient's date of 
birth.
     Address: Would include the patient's current primary 
address.
     Zip code: Would represent the zip code of the patient's 
current primary address. Zip codes for other addresses would be 
optional but, if included, would need to include date ranges for 
when the zip codes were applicable.
     Patient identifier(s): would include one or more of the 
identifiers used by a health care provider to uniquely identify the 
patient to which the underlying metadata pertain. For example, the 
last four digits of the social security number; the patient's 
driver's license number; the patient identification number assigned 
to the patient by a health care provider; or any combination of the 
above.
    For each of the above elements, consistent with the HIT 
Standards Committee's recommendation, we would consider requiring 
that they be expressed according to HL7 CDA R2 header syntax. We 
would not expect, however, to require the implementation of the 
surrounding structure that a complete, valid HL7 CDA R2 header would 
include. Rather, our intent would be to leverage the way in which 
the HL7 CDA R2 header expresses how each data element would be 
represented and not to require that the HL7 CDA R2 header's 
structure also be implemented.
    Question 1: Are there additional metadata elements within the 
patient identity category that we should consider including? If so, 
why and what purpose would the additional element(s) serve? Should 
any of the elements listed above be removed? If so, why?
    Question 2: In cases where individuals lack address information, 
would it be appropriate to require that the current health care 
institution's address be used?
    In addition to the patient identity metadata that we would 
expect to be expressed using the HL7 CDA R2 header, we are 
considering requiring an additional metadata element to be included 
for ``display name.'' In this case, and as discussed by the HIT 
Standards Committee, we currently believe that extending name 
metadata beyond the HL7 CDA R2 header requirements\3\ to include a 
display name is important to accommodate names that do not always 
follow a ``first

[[Page 48774]]

name, middle name, last name'' format or to identify newborns whose 
names have not yet been assigned. We would expect to require that 
the display name metadata element be an XML element whose value is a 
string that captures the patient's name as it should be displayed or 
written. Without this addition, we believe that many systems may 
accidentally parse parts of a patient's name incorrectly due to the 
fact that in some cultures names are not structured according to 
first, middle, and last name segments. For example, the naming 
conventions in some cultures do not follow this structure and can 
result in the last name being incorrectly parsed or transposed. 
Therefore, for this metadata element, we are considering whether to 
propose that a full name string element be included to facilitate 
matching in cases where name components are incorrectly categorized.
---------------------------------------------------------------------------

    \3\ The HL7 CDA R2 schema's definition of name only supports the 
following components: Delimiter, family, given, prefix and suffix.
---------------------------------------------------------------------------

    Question 3: How difficult would it be today to include a 
``display name'' metadata element? Should a different approach be 
considered to accommodate the differences among cultural naming 
conventions?
    We are also considering whether to propose as a second 
extension, beyond the HL7 CDA R2, the use of a uniform resource 
identifier (URI) to act as a namespace for the patient identifier 
metadata as opposed to the use of an object identifier (OID) as 
specified in HL7 CDA R2. Currently, the definition of the ``id 
root'' attribute in the HL7 CDA R2 header is defined to only accept 
OIDs, universally unique identifiers (UUIDs), or specific HL7 
reserved identifiers, none of which can hold a URI. A URI could be 
used as a means to identify the associated ID type that would be 
used. For instance, https://www.nh.gov/safety/divisions/dmv gov/safety/divisions/dmv''/> indicates that the ID type is a New 
Hampshire driver's license. This extension would allow for an 
extensible, flexible mechanism to uniquely identify an individual, 
without having to explicitly specify what type of identifier is 
used. In the event multiple types of identifiers are used, a means 
to properly attribute the right information to each identifier would 
be necessary. We believe a URI can effectively serve this purpose.

2. Provenance Metadata Standards

    We are considering the following standard set of provenance 
metadata recommended by the HIT Standards Committee. The standard 
set would include the following data elements expressed according to 
the requirements explained below--a tagged data element (TDE) 
identifier; a time stamp; and the actor, the actor's affiliation, 
and the actor's digital certificate. These provenance metadata 
function as part of a ``wrapper'' that would convey the ``who, what, 
where, and when'' of the data being electronically exchanged. As 
with patient identity metadata, we would expect these provenance 
metadata elements to be expressed according to HL7 CDA R2 header 
syntax requirements, where applicable.
     TDE identifier: Would allow for other TDEs to link to 
this particular instance, thus preserving clinical context, and 
allow users to keep a log of the set of TDEs used for a particular 
task. For example, a TDE containing diagnostic study information 
could contain the identifier of another TDE that describes the 
encounter that led to that study.
     Time stamp: Would express when the content to which the 
metadata pertains was digitally signed.
     Actor and actor's affiliation: Would, in the form of a 
digital certificate, include the name of the actor who digitally 
signed the content to which the metadata pertains and the 
organizational affiliation of the actor. The HIT Standards Committee 
noted that this scheme allows for exchanges to occur involving 
either organizational actors or individual actors.
    The HIT Standards Committee also recommended that the X.509 
standard for certificates be used to digitally sign the content to 
which the metadata pertains. It noted that that digital certificates 
and digital signatures could be used to provide non-repudiation and 
tamper-resistance. The HIT Standards Committee further acknowledged 
that while its expectation was that an actor and its affiliation 
would be expressed in an X.509 certificate that there should be 
optional metadata fields for actor and actor affiliation for reasons 
including situations where EHR technology can understand the XML 
format of the HL7 CDA R2 header syntax, but cannot process more 
complex cryptographic signatures. As a final recommendation on 
provenance, the HIT Standards Committee recommended an optional 
portion of the actor/affiliation metadata should point to the entity 
record in the Enterprise-Level Provider Directory, which may be a 
URL (this concept is included in the metadata example illustrated 
below).
    Question 4: Are there additional metadata elements within the 
provenance category that we should consider including? If so, why 
and what purpose would the additional element(s) serve? Should any 
of the elements listed above be removed? If so, why?
    Generally, as recommended by the HIT Standards Committee, the 
metadata elements for time stamp, the actor, the actor's 
affiliation, and the actor's digital certificate all rely on one 
security architecture, the use of digital certificates. We are 
considering whether for the purposes of adopting metadata standards 
it would be beneficial to decouple the metadata elements from a 
particular security architecture. In short, we are contemplating 
whether it would be more effective and appropriate to adopt 
provenance metadata elements that do not rely on a single security 
architecture, but rather can be used in various security 
architectures.
    Question 5: With respect to the provenance metadata elements for 
time stamp, actor, and actor's affiliation, would it be more 
appropriate to require that those elements be expressed in XML 
syntax instead of relying on their inclusion in a digital 
certificate? For example, time stamp could express when the document 
to which the metadata pertain was created as opposed to when the 
content was digitally signed. Because this approach would decouple 
the provenance metadata from a specific security architecture, would 
its advantages outweigh those of digital certificates?

3. Privacy Metadata Standards

    At the outset, we note that the HIT Standards Committee made its 
recommendations on privacy metadata standards with the underlying 
assumption that any personally identifiable information would be 
exchanged in an appropriately secure manner (i.e., encrypted). In 
its assumed model, the HIT Standards Committee basically envisioned 
clinical content which is ``double wrapped''--first according to the 
metadata standards we are considering and then encrypted prior to 
the entire package of data being transported--meaning only the 
recipient of the entire package would be able to view the metadata 
once it has been decrypted. In other words, and from ONC's 
perspective, if circumstances would require the content to which the 
metadata pertain to be encrypted, the metadata would also be 
encrypted.
    As recommended by the HIT Standards Committee, we are 
considering the following standard set of privacy metadata which 
would include the following data elements expressed according to the 
requirements explained below--a ``policy pointer'' and content 
metadata elements.
     Policy pointer: would be a Uniform Resource Locator 
(URL) that points to the privacy policy in effect at the time the 
tagged data element is released. This metadata element would support 
the potential for external privacy policy registries to be used.
     Content metadata: would be used to represent those 
elements needed to implement and reflect organizational policies as 
well as those federal and state laws that would be applicable to the 
underlying data to which this metadata would pertain. Content 
metadata would be comprised of two components:
    [cir] Data type: would describe the underlying data to which 
this metadata pertains from a clinical perspective. For this 
metadata element, we are considering whether to propose that Logical 
Observation Identifiers Names and Codes (LOINC) codes be used to 
provide additional granularity.
    [cir] Sensitivity: HL7 vocabulary for sensitivity would be used 
to indicate at a more granular level the type of underlying data to 
which this metadata pertains in order for the potential for 
automated privacy filters to apply more stringent protections to the 
data in the event it is selected for a future disclosure.
    Again, we would expect that these privacy metadata would be 
expressed according to the HL7 CDA R2 header syntax requirements.
    Question 6: Are there additional metadata elements within the 
privacy category that we should consider including? If so, why and 
what purpose would the additional element(s) serve? Should any of 
the elements listed above be removed? If so, why?
    Question 7: What experience, if any, do stakeholders have 
regarding policy pointers? If implemented, in what form and for what 
purpose have policy pointers been used (for instance, to point to 
state, regional, or organizational policies, or to capture in a 
central location a patient's preferences regarding the sharing of 
their health information)? Could helpful concepts be drawn from the 
Health Information

[[Page 48775]]

Technology Standards Panel (HITSP) Transaction Package 30 (TP30) 
``Manage Consent Directives?''
    Question 8: Is a policy pointer metadata element a concept that 
is mature enough to include as part of the metadata standards we are 
considering? More specifically, we request comment on issues related 
to the persistence of URLs that would point to privacy policies 
(i.e., what if the URL changes over time) and the implication of 
changes in privacy policies over time (i.e., how would new policy 
available at the URL apply to data that was transmitted at an 
earlier date under an older policy that was available at the same 
URL)?
    Question 9: Assuming that a policy pointer metadata element 
pointed to one or more privacy policies, what standards would need 
to be in place for these policies to be computable?
    Question 10: With respect to the privacy category and content 
metadata related to ``data type,'' the HIT Standards Committee 
recommended the use of LOINC codes to provide additional 
granularity. Would another code or value set be more appropriate? If 
so, why?
    Question 11: The HIT Standards Committee recommended developing 
and using coded values for sensitivity to indicate that the tagged 
data may require special handling per established policy. It 
suggested that a possible starter set could be based on expanded 
version of the HL7 ConfidentialityByInfoType value set and include: 
``substance abuse; mental health; reproductive health; sexually 
transmitted disease; HIV/AIDS; genetic information; violence; and 
other.'' During this discussion, several members of the HIT 
Standards Committee raised concerns that a recipient of a summary 
care record tagged according to these sensitivity values could make 
direct inferences about the data to which the metadata pertain. 
Consistent with this concern, HL7 indicates in its documentation 
that for health information in transit, implementers should avoid 
using the ConfidentialityByInfoType value set. HL7 also indicates 
that utilizing another value set, the ConfidentialityByAccessKind 
value set which describes privacy policies at a higher level, 
requires careful consideration prior to use due to the fact that 
some items in the code set were not appropriate to use with actual 
patient data. In addition, the HIT Standards Committee recommended 
against adopting an approach that would tag privacy policies 
directly to the data elements. What kind of starter value set would 
be most useful for a sensitivity metadata element to indicate? How 
should those values be referenced? Should the value set be small and 
general, or larger and specific, or some other combination? Does a 
widely used/commonly agreed to value set already exist for 
sensitivity that we should considering using?
    Question 12: In its recommendations on privacy metadata, the HIT 
Standards Committee concluded that it was not viable to include the 
policy applicable to each TDE because policy changes over time. Is 
this the appropriate approach? Are there circumstances in which it 
would be appropriate to include privacy preferences or policy with 
each data tagged element? If so, under what circumstances? What is 
the appropriate way to indicate that exchanged information may not 
be re-disclosed without obtaining additional patient permission? Are 
there existing standards to communicate this limitation?

B. Metadata Example

    The following is a complete example of how the standard sets of 
metadata elements for the three categories discussed above could be 
expressed.

--------------------------------------------------------------------------------------------------------------------------------------------------------
             Metadata element                     Expressed according to HL7 CDA R2 requirements (where applicable)                     Notes
--------------------------------------------------------------------------------------------------------------------------------------------------------
Provenance--TDE ID.......................  
Privacy--Content Data Type...............  
Provenance--Timestamp....................                                          ............................
Privacy--Content Sensitivity.............                                              ............................
Patient ID--ID...........................        Note that in a CDA R2
                                                                                                                             Header, the root attribute
                                                                                                                             would typically be an OID
Patient ID--Address......................   1234 Main St. Apt 3     ............................
                                           Bedford
                                           MA/state>
                                           01730
                                                                                                                     ............................
Patient ID--Name.........................                                                                             Note that displayName is not
                                                                                                                             part of the HL7 CDA R2
                                                                                                                             header.
                                           Dr.                                            ............................
                                            John                                                             ............................
                                           William                                                           ............................
                                           Smith                                                           ............................
                                           Dr. John William Smith                                ............................
                                                                                                                     ............................
Patient ID--DOB..........................                                                    ............................
Provenance--Actor........................                                   Entry is not part of the
                                                                                                                             HL7 CDA R2 header.
                                                                                                                      ............................
                                           Smith                                                           ............................
                                           John                                                              ............................
                                           Dr.                                                             ............................
                                                                                                                     ............................
                                           
Privacy--Policy Pointer..................  
Provenance--Affiliation..................   
                                           St. Elsewhere Hospital                                              ............................
                                                                                           ............................

[[Page 48776]]

 
                                                                                                  ............................
--------------------------------------------------------------------------------------------------------------------------------------------------------

III. Additional Questions

    To better inform future proposals, we seek public comment on the 
following specific questions. Commenters are also welcome to provide 
feedback on any of the considerations and expectations we expressed 
above even where a specific question is not asked.
    Question 13: With respect to the first use case identified by 
the HIT Policy Committee for when metadata should be assigned (i.e., 
a patient obtaining their summary care record from a health care 
provider), how difficult would it be for EHR technology developers 
to include this capability in EHR technology according to the 
standards discussed above in order to support meaningful use Stage 
2?
    Question 14: Assuming we were to require that EHR technology be 
capable of meeting the first use case identified by the HIT Policy 
Committee, how much more difficult would it be to design EHR 
technology to assign metadata in other electronic exchange scenarios 
in order to support meaningful use Stage 2? Please identify any 
difficulties and the specific electronic exchange scenario(s).
    Question 15: Building on Question 14, and looking more long 
term, how would the extension of metadata standards to other forms 
of electronic health information exchange affect ongoing messaging 
and transactions? Are there other potential uses cases (e.g., 
exchanging information for treatment by a health care provider, for 
research, or public health) for metadata that we should be 
considering? Would the set of metadata currently under consideration 
support these different use cases or would we need to consider other 
metadata elements?
    Question 16: Are there other metadata categories besides the 
three (patient identity, provenance, and privacy) we considered 
above that should be included? If so, please identify the metadata 
elements that would be within the category or categories, your 
rationale for including them, and the syntax that should be used to 
represent the metadata element(s).
    Question 17: In addition to the metadata standards and data 
elements we are considering, what other implementation factors or 
contexts should be considered as we think about implementation 
specifications for these metadata standards?
    Question 18: Besides the HL7 CDA R2 header, are there other 
standards that we should consider that can provide an equivalent 
level of syntax and specificity? If so, do these alternative 
standards offer any benefits with regard to intellectual property 
and licensing issues?
    Question 19: The HL7 CDA R2 header contains additional 
``structural'' XML elements that help organize the header and enable 
it to be processed by a computer. Presently, we are considering 
leveraging the HL7 CDA R2 header insofar as the syntax requirement 
it expresses relate to a metadata element we are considering. Should 
we consider including as a proposed requirement the additional 
structures to create a valid HL7 CDA R2 header?
    Question 20: Executive Order (EO) 13563 entitled ``Improving 
Regulation and Regulatory Review'' directs agencies ``to the extent 
feasible, [to] specify performance objectives, rather than 
specifying the behavior or manner of compliance that regulated 
entities must adopt;'' (EO 13563, Section 1(b)(4)). Besides the 
current standards we are considering, are there performance-oriented 
standards related to metadata that we should consider?

    Dated: August 4, 2011.
Kathleen Sebelius,
Secretary.

[FR Doc. 2011-20219 Filed 8-8-11; 8:45 am]
BILLING CODE 4150-45-P