Federal Register / Vol. 76, No. 153 / Tuesday, August 9, 2011 / Proposed Rules 48769 

PASSENGER CARS

Model 

year 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 

a ....... 30.96 32.65 33.84 35.07 36.47 38.02 39.79 41.64 43.58 45.61 

b ....... 41.09 43.61 45.21 46.87 48.74 50.83 53.21 55.71 58.32 61.07 

c ....... 0.0005308 0.0005131 0.0004954 0.0004783 0.0004603 0.0004419 0.0004227 0.0004043 0.0003867 0.0003699 

d ....... 0.002573 0.001896 0.001811 0.001729 0.001643 0.001555 0.001463 0.001375 0.001290 0.001210 

e ....... ....................... 31.51 31.51 31.51 31.51 31.51 31.51 31.51 31.51 31.51 

f ........ ....................... 42.06 42.06 42.06 42.06 42.06 42.06 42.06 42.06 42.06 

g ....... ....................... 0.0005308 0.0005308 0.0005308 0.0005308 0.0005308 0.0005308 0.0005308 0.0005308 0.0005308 

h ....... ....................... 0.002010 0.002010 0.002010 0.002010 0.002010 0.002010 0.002010 0.002010 0.002010 

TRUCKS

Model 

year 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 

a ....... 24.74 25.09 25.20 25.25 25.25 25.25 26.29 27.53 28.83 30.19 

b ....... 34.42 36.26 37.36 38.16 39.11 41.80 43.79 45.89 48.09 50.39 

c ....... 0.0004546 0.0005484 0.0005358 0.0005265 0.0005140 0.0004820 0.0004607 0.0004404 0.0004210 0.0004025 

d ....... 0.010413 0.005097 0.004797 0.004623 0.004494 0.004164 0.003944 0.003735 0.003534 0.003343 

e ....... ....................... 25.09 25.20 25.25 25.25 25.25 25.25 25.25 25.25 25.25 

f ........ ....................... 35.10 35.31 35.41 35.41 35.41 35.41 35.41 35.41 35.41 

g ....... ....................... 0.0004546 0.0004546 0.0004546 0.0004546 0.0004546 0.0004546 0.0004546 0.0004546 0.0004546 

h ....... ....................... 0.009851 0.009682 0.009603 0.009603 0.009603 0.009603 0.009603 0.009603 0.009603 

a = Fuel Economy Value for Lower Footprint Cutpoint [mpg]. 

b = Fuel Economy Value for Upper Footprint Cutpoint [mpg]. 

c = Slope [gallons per mile per square foot]. 

d = Intercept [gallons per mile]. 

e = Fuel Economy Value for Lower Footprint Cutpoint [mpg] for Floor Curve. 

f = Fuel Economy Value for Upper Footprint Cutpoint [mpg] for Target Floor Curve. 

g = Slope [gallons per mile per square foot] for Target Floor Curve. 

h = Intercept [gallons per mile] for Target Floor Curve. 

Dated: July 29, 2011 

Ray LaHood, 

Secretary, Department of Transportation. 

Dated: July 29, 2011. 

Lisa P. Jackson, 

Administrator, Environmental Protection 

Agency. 

[FR Doc. 2011–19905 Filed 8–8–11; 8:45 am] 

BILLING CODE 6560–50–C 

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. 

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


jlentini on DSK4TPTVN1PROD with PROPOSALS
48770 Federal Register / Vol. 76, No. 153 / Tuesday, August 9, 2011 / Proposed Rules 

1PHSA 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). 

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


jlentini on DSK4TPTVN1PROD with PROPOSALS
Federal Register / Vol. 76, No. 153 / Tuesday, August 9, 2011 / Proposed Rules 48771 

2http://www.whitehouse.gov/administration/eop/ 

ostp/pcast 

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. 

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 


jlentini on DSK4TPTVN1PROD with PROPOSALS
48772 Federal Register / Vol. 76, No. 153 / Tuesday, August 9, 2011 / Proposed Rules 

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 ONCrelated 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 reshare 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 ONCcommissioned 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. 


jlentini on DSK4TPTVN1PROD with PROPOSALS
Federal Register / Vol. 76, No. 153 / Tuesday, August 9, 2011 / Proposed Rules 48773 

3The HL7 CDA R2 schema’s definition of name 

only supports the following components: Delimiter, 

family, given, prefix and suffix. 

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 requirements3 to include a 

display name is important to accommodate 

names that do not always follow a ‘‘first 


jlentini on DSK4TPTVN1PROD with PROPOSALS
48774 Federal Register / Vol. 76, No. 153 / Tuesday, August 9, 2011 / Proposed Rules 

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. 

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, <id 

extension=‘‘1234567’’ root=‘‘http://www.nh. 

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

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

Æ 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 


jlentini on DSK4TPTVN1PROD with PROPOSALS
Federal Register / Vol. 76, No. 153 / Tuesday, August 9, 2011 / Proposed Rules 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 ... <id extension=‘‘http://stelsewhere.com/id/12345’’ assigningAuthority=‘‘St. Elsewhere Hospital’’/> 

Privacy—Content Data 

Type.

<code code=‘‘11488–4’’ displayName=‘‘Consultation note’’ codeSystemName=‘‘LOINC’’/> 

Provenance— 

Timestamp.

<effectiveTime value=‘‘20101217093047’’/> 

Privacy—Content Sensitivity.<confidentialityCode code=‘‘Other’’/> 

Patient ID—ID .............. <id extension=‘‘1234567’’ root=‘‘http://www.nh.gov/safety/divisions/dmv/’’> Note that in a CDA 

R2 Header, the 

root attribute would 

typically be an OID 

Patient ID—Address ..... <addr use=‘‘HP’’> <streetAddressLine>1234 Main St. Apt 3</streetAddressLine> 

<city>Bedford</city> 

<state>MA/state> 

<postalCode>01730</postalCode> 

</addr> 

Patient ID—Name ........ <name> Note that 

displayName is not 

part of the HL7 

CDA R2 header. 

<prefix qualifier=‘‘AC’’>Dr.</prefix> 

<given> John</given> 

<given>William</given> 

<family>Smith</family> 

<displayName>Dr. John William Smith</displayName> 

</name> 

Patient ID—DOB .......... <birthTime value=‘‘19600427’’/> 

Provenance—Actor ...... <assignedPerson> <providerDirectory 

Entry href=‘‘http://providerdirectory.org/1234’’/> 

Note that 

providerDirectory 

Entry is not part of 

the HL7 CDA R2 

header. 

<name> 

<family>Smith</family> 

<given>John</given> 

<prefix>Dr.</prefix> 

</name> 

</assignedPerson> 

Privacy—Policy Pointer <id extension=‘‘http://policy.example.org/9876543’’ root=‘‘policy_pointer_oid’’/> 

Provenance—Affiliation <representedOrganization> <id extension=‘‘http://stelsewhere.com/’’ assigningAuthority=‘‘St. 

Elsewhere Hospital’’/> 

<name>St. Elsewhere Hospital</name> 

<telecom use=‘‘1–800–555–1234’’/> 


jlentini on DSK4TPTVN1PROD with PROPOSALS
48776 Federal Register / Vol. 76, No. 153 / Tuesday, August 9, 2011 / Proposed Rules 

Metadata element Expressed according to HL7 CDA R2 requirements (where applicable) Notes 

</representedOrganization> 

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 

DEPARTMENT OF DEFENSE 

GENERAL SERVICES 

ADMINISTRATION 

NATIONAL AERONAUTICS AND 

SPACE ADMINISTRATION 

48 CFR Part 42 

[FAR Case 2009–042; Docket 2011–0087, 

Sequence 1] 

RIN 9000–AM09 

Federal Acquisition Regulation; 

Documenting Contractor Performance; 

Correction 

AGENCY: Department of Defense (DoD), 

General Services Administration (GSA), 

and National Aeronautics and Space 

Administration (NASA). 

ACTION: Proposed rule; correction and 

extension of comment date. 

SUMMARY: This document corrects the 

proposed changes published in the 

Federal Register of June 28, 2011, 

regarding the proposed rule for 

Documenting Contractor Performance 

and extends the comment closing date 

by 30 days. 

DATES: The comment period for the 

proposed rule published June, 28, 2011, 

at 76 FR 37704, is extended. Comments 

will be received until September 8, 

2011. 

FOR FURTHER INFORMATION CONTACT: Mr. 

Curtis E. Glover, Sr., Procurement 

Analyst, at (202) 501–1448. Please cite 

FAR Case 2009–042. 

SUPPLEMENTARY INFORMATION: This 

document corrects the proposed 

changes published in the Federal 

Register of June 28, 2011, regarding the 

proposed rule for Documenting 

Contractor Performance (75 FR 37704) 

and extends the comment closing date 

by 30 days. Text already in the Federal 

Acquisition Regulation was 

inadvertently omitted from the 

restatement of section 42.1503. The text 

was not intended to be removed, and is 

being restored at 42.1503(d) and 

42.1503(h)(1) in the proposed rule. 

Correction 

In the proposed rule FR Doc. 2011– 

16169, beginning on page 37705, in 3rd 

column, in the issue of Tuesday, June 

28, 2011, make the following correction, 

in the instructions of section 42.1503. 

42.1503 [Corrected] 

1. Section 42.1503 is corrected to read 

as follows: 

42.1503 Procedures. 

(a) Agency procedures for the past 

performance evaluation system shall 

generally provide for input to the 

evaluations from the technical office, 

contracting office and, where 

appropriate, end users of the product or 

service. Agency procedures shall 

identify and assign past performance 

evaluation roles and responsibilities to 

those individuals responsible for 

preparing interim and final performance 

evaluations (e.g., contracting officer 

representatives and program managers). 

If agency procedures do not specify the 

individuals responsible for past 

performance evaluation duties, the 

contracting officer will remain 

responsible for this function. Those 

individuals identified may obtain 

information for the evaluation of 

performance from the program office, 

administrative contracting office, audit 

office, end users of the product or 

service, and any other technical or 

business advisor, as appropriate. Interim 

evaluations shall be prepared on an 

annual basis, in accordance with agency 

procedures. 

(b)(1) The evaluation report should 

reflect how the contractor performed. 

The report should include clear relevant 

information that accurately depicts the 

contractor’s performance, and be based 

on objective facts supported by program 

and contract performance data. The 

evaluations should be tailored to the 

contract type, size, content, and 

complexity of the contractual 

requirements. 


jlentini on DSK4TPTVN1PROD with PROPOSALS