80 FR 16804 - 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications
DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary
Federal Register Volume 80, Issue 60 (March 30, 2015)
Page Range
16804-16921
FR Document
2015-06612
This notice of proposed rulemaking introduces a new edition of certification criteria (the 2015 Edition health IT certification criteria or ``2015 Edition''), proposes a new 2015 Edition Base EHR definition, and proposes to modify the ONC Health IT Certification Program to make it open and accessible to more types of health IT and health IT that supports various care and practice settings. The 2015 Edition would also establish the capabilities and specify the related standards and implementation specifications that Certified Electronic Health Record (EHR) Technology (CEHRT) would need to include to, at a minimum, support the achievement of meaningful use by eligible professionals (EPs), eligible hospitals, and critical access hospitals (CAHs) under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) when such edition is required for use under these programs.
Federal Register, Volume 80 Issue 60 (Monday, March 30, 2015)
[Federal Register Volume 80, Number 60 (Monday, March 30, 2015)]
[Proposed Rules]
[Pages 16804-16921]
From the Federal Register Online [www.thefederalregister.org]
[FR Doc No: 2015-06612]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Part 170
RIN 0991-AB93
2015 Edition Health Information Technology (Health IT)
Certification Criteria, 2015 Edition Base Electronic Health Record
(EHR) Definition, and ONC Health IT Certification Program Modifications
AGENCY: Office of the National Coordinator for Health Information
Technology (ONC), Department of Health and Human Services (HHS).
ACTION: Notice of proposed rulemaking with comment period.
-----------------------------------------------------------------------
SUMMARY: This notice of proposed rulemaking introduces a new edition of
certification criteria (the 2015 Edition health IT certification
criteria or ``2015 Edition''), proposes a new 2015 Edition Base EHR
definition, and proposes to modify the ONC Health IT Certification
Program to make it open and accessible to more types of health IT and
health IT that supports various care and practice settings. The 2015
Edition would also establish the capabilities and specify the related
standards and implementation specifications that Certified Electronic
Health Record (EHR) Technology (CEHRT) would need to include to, at a
minimum, support the achievement of meaningful use by eligible
professionals (EPs), eligible hospitals, and critical access hospitals
(CAHs) under the Medicare and Medicaid EHR Incentive Programs (EHR
Incentive Programs) when such edition is required for use under these
programs.
DATES: To be assured consideration, written or electronic comments must
be received at one of the addresses provided below, no later than 5
p.m. on May 29, 2015.
ADDRESSES: You may submit comments, identified by RIN 0991-AB93, by any
of the following methods (please do not submit duplicate comments).
Because of staff and resource limitations, we cannot accept comments by
facsimile (FAX) transmission.
Federal eRulemaking Portal: Follow the instructions for
submitting comments. Attachments should be in Microsoft Word, Microsoft
Excel, or 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: 2015 Edition Health IT Certification
Criteria Proposed Rule, 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: 2015 Edition
Health IT Certification Criteria Proposed Rule, 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.)
Enhancing the Public Comment Experience: To facilitate public
comment on this proposed rule, a copy will be made available in
Microsoft Word format. We believe this version will make it easier for
commenters to access and copy portions of the proposed rule for use in
their individual comments. Additionally, a separate document will be
made available for the public to use to provide comments on the
proposed rule. This document is meant to provide the public with a
simple and organized way to submit comments on the certification
criteria, associated standards and implementation specifications, and
respond to specific questions posed in the preamble of the proposed
rule. While use of this document is entirely voluntary, we encourage
commenters to consider using the document in lieu of unstructured
comments or to use it as an addendum to narrative cover pages. Roughly
30% of the public comments submitted to our past two editions of
certification criteria proposed rules used the provided template, which
greatly assisted in our ability to rapidly process and more accurately
categorize public comments. Because of the technical nature of this
proposed rule, we believe that use of the document may facilitate our
review and understanding of the comments received. The Microsoft Word
version of the proposed rule and the document that can be used for
providing comments can be found at http://www.regulations.gov as part
of this proposed rule's docket and on ONC's Web site (http://www.healthit.gov).
Inspection of Public Comments: All comments received before the
close of the comment period will be available for public inspection,
including any personally identifiable or confidential business
information that is included in a comment. Please do not include
anything in your comment submission that you do not wish to share with
the general public. Such information includes, but is not limited to: a
person's social security number; date of birth; driver's license
number; state identification number or foreign country equivalent;
passport number; financial account number; credit or debit card number;
any personal health information; or any business information that could
be considered proprietary. We will post all comments that are received
before the close of the comment period at http://www.regulations.gov.
Docket: For access to the docket to read background documents or
comments received, go to http://www.regulations.gov or the Department
of Health and Human Services, Office of the National Coordinator for
Health Information Technology, Hubert H. Humphrey Building, Suite 729D,
200 Independence Ave SW., Washington,
[[Page 16805]]
DC 20201 (call ahead to the contact listed below to arrange for
inspection).
FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy,
Office of the National Coordinator for Health Information Technology,
202-690-7151.
SUPPLEMENTARY INFORMATION:
Commonly Used Acronyms
API Application Programming Interface
CAH Critical Access Hospital
CDA Clinical Document Architecture
CDC Centers for Disease Control and Prevention
CDS Clinical Decision Support
CEHRT Certified Electronic Health Record Technology
CFR Code of Federal Regulations
CHPL Certified Health IT Product List
CLIA Clinical Laboratory Improvement Amendments
CMS Centers for Medicare & Medicaid Services
CQM Clinical Quality Measure
EHR Electronic Health Record
HHS Department of Health and Human Services
HISP Health Information Service Providers
HIT Health Information Technology
HITPC HIT Policy Committee
HITSC HIT Standards Committee
HL7 Health Level Seven
IG Implementation Guide
LOINC[supreg] Logical Observation Identifiers Names and Codes
ONC Office of the National Coordinator for Health Information
Technology
SNOMED CT[supreg] Systematized Nomenclature of Medicine Clinical
Terms
Table of Contents
I. Executive Summary
A. Purpose of Regulatory Action
B. Summary of Major Provisions
1. Overview of the 2015 Edition Health IT Certification Criteria
2. Base EHR Definition and Certified EHR Technology Definition
3. The ONC Health IT Certification Program and Health IT Module
C. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation Specifications, and Certification
Criteria
2. HIT Certification Programs
B. Regulatory History
1. Standards, Implementation Specifications, and Certification
Criteria Rules
2. Medicare and Medicaid EHR Incentive Programs Rules
3. ONC Health IT Certification Programs Rules
III. Provisions of the Proposed Rule Affecting Standards,
Implementation Specifications, Certification Criteria, and
Definitions
A. 2015 Edition Health IT Certification Criteria
1. Applicability
2. Standards and Implementation Specifications
3. Certification Criteria
4. 2015 Edition Gap Certification Eligibility Table
5. Pharmacogenomics Data--Request for Comment
B. Definitions
1. Base EHR Definitions
2. Certified EHR Technology Definition
3. Common Clinical Data Set Definition
4. Cross-Referenced FDA Definitions
IV. Provisions of the Proposed Rule Affecting the ONC Health IT
Certification Program
A. Subpart E--ONC Health IT Certification Program
B. Modifications to the ONC Health IT Certification Program
1. Health IT Modules
2. ``Removal'' of Meaningful Use Measurement Certification
Requirements
3. Types of Care and Practice Settings
4. Referencing the ONC Health IT Certification Program
C. Health IT Module Certification Requirements
1. Privacy and Security
2. Design and Performance (Sec. 170.315(g))
D. Principles of Proper Conduct for ONC-ACBs
1. ``In-the-Field'' Surveillance and Maintenance of
Certification
2. Transparency and Disclosure Requirements
3. Open Data Certified Health IT Product List (CHPL)
4. Records Retention
5. Complaints Reporting
6. Adaptations and Updates of Certified Health IT
E. ``Decertification'' of Health IT--Request for Comment
V. Response to Comments
VI. Incorporation by Reference
VII. Collection of Information Requirements
VIII. Regulatory Impact Statement
A. Statement of Need
B. Overall Impact
1. Executive Orders 12866 and 13563--Regulatory Planning and
Review Analysis
2. Regulatory Flexibility Act
3. Executive Order 13132--Federalism
4. Unfunded Mandates Reform Act of 1995
I. Executive Summary
A. Purpose of Regulatory Action
Building on past rulemakings, this proposed rule further identifies
how health IT certification can support the establishment of an
interoperable nationwide health information infrastructure. It reflects
stakeholder feedback received through various outreach initiatives,
including the regulatory process, and is designed to broadly support
the health care continuum through the use of certified health IT. To
achieve this goal, this rule proposes to:
Improve interoperability for specific purposes by adopting
new and updated vocabulary and content standards for the structured
recording and exchange of health information, including a Common
Clinical Data Set composed primarily of data expressed using adopted
standards; and rigorously testing an identified content exchange
standard (Consolidated Clinical Document Architecture (C-CDA));
Facilitate the accessibility and exchange of data by
including enhanced data portability, transitions of care, and
application programming interface (API) capabilities in the 2015
Edition Base EHR definition;
Establish a framework that makes the ONC Health IT
Certification Program open and accessible to more types of health IT,
health IT that supports a variety of care and practice settings,
various HHS programs, and public and private interests;
Support the Medicare and Medicaid EHR Incentive Programs
(EHR Incentive Programs) through the adoption of a set of certification
criteria that align with proposals for Stage 3;
Address health disparities by providing certification: To
standards for the collection of social, psychological, and behavioral
data; for the exchange of sensitive health information (Data
Segmentation for Privacy); and for the accessibility of health IT;
Ensure all health IT presented for certification possess
the relevant privacy and security capabilities;
Improve patient safety by: Applying enhanced user-center
design principles to health IT, enhancing patient matching, requiring
relevant patient information to be exchanged (e.g., Unique Device
Identifiers), improving the surveillance of certified health IT, and
making more information about certified products publicly available and
accessible;
Increase the reliability and transparency of certified
health IT through surveillance and disclosure requirements; and
Provide health IT developers with more flexibility and
opportunities for certification that support both interoperability and
innovation.
B. Summary of Major Provisions
1. Overview of the 2015 Edition Health IT Certification Criteria
The 2015 Edition health IT certification criteria (``2015
Edition'') would facilitate greater interoperability for several
clinical health information purposes and enable health information
exchange through new and enhanced certification criteria, standards,
and implementation specifications. It incorporates changes that are
designed to spur innovation, open new market opportunities, and provide
more choices to providers when it comes to electronic
[[Page 16806]]
health information exchange. To achieve these goals, we propose a new
``Application Access to Common Clinical Data Set'' certification
criterion that would require the demonstration of an API that responds
to data requests for any one of the data referenced in the Common
Clinical Data Set as well as for all of the data referenced in the
Common Clinical Data Set. To further validate the continued
interoperability of certified health IT and the ability to exchange
health information, we propose a new certification criterion that would
rigorously assess a product's C-CDA creation performance (for both C-
CDA version 1.1 and 2.0) when presented for certification for such
capabilities.
2. Definitions
a. Base EHR Definitions
We propose to adopt a Base EHR definition specific to the 2015
Edition (i.e., a 2015 Edition Base EHR definition) at Sec. 170.102 and
rename the current Base EHR definition at Sec. 170.102 as the 2014
Edition Base EHR definition. For the proposed 2015 Edition Base EHR
definition, it would differ from the 2014 Edition Base EHR definition
in the following ways:
It does not include privacy and security capabilities and
certification criteria. We believe privacy and security capabilities
would be more appropriately addressed through our new proposed approach
for the privacy and security certification of Health IT Modules to the
2015 Edition, as discussed under ``Privacy and Security'' in section
IV.C.1 of the preamble. Our new privacy and security approach would
eliminate eligible professionals (EPs)', eligible hospitals', and
critical access hospitals (CAHs)' responsibilities to ensure that they
have technology certified to all the necessary privacy and security
criteria. Rather, as part of certification, health IT developers would
need to meet applicable privacy and security certification criteria.
It only includes the capability to record and export CQM
data (Sec. 170.315(c)(1)). To note, the capabilities to import,
calculate and report CQM data are not included in the proposed 2015
Edition Base EHR definition or any other CQM-related requirements.
Please refer to the ``Clinical Quality Measures'' section (III.A.3)
later in the preamble for a more detailed discussion of the CQM
certification criteria. Please also see the EHR Incentive Programs
Stage 3 proposed rule published elsewhere in this issue of the Federal
Register for proposals related to CQMs, including the CEHRT definition
proposal.
It includes the 2015 Edition ``smoking status,''
``implantable device list,'' and ``application access to Common
Clinical Data Set'' certification criteria. For a detailed discussion
of these certification criteria, please refer to section III.A.3 of the
preamble.
It includes the proposed 2015 Edition certification
criteria that correspond to the remaining 2014 Edition certification
criteria referenced in the ``2014 Edition'' Base EHR definition (i.e.,
Computerized Provider Order Entry (CPOE), demographics, problem list,
medication list, medication allergy list, clinical decision support
(CDS), transitions of care, data portability, and relevant transport
certification criteria). On the inclusion of transport certification
criteria, we propose to include the ``Direct Project'' criterion (Sec.
170.315(h)(1)) as well as the ``Direct Project, Edge Protocol and XDR/
XDM'' \1\ criterion (Sec. 170.315(h)(2)) as equivalent alternative
means for meeting the 2015 Edition Base EHR definition for the reasons
discussed under ``Transport Methods and Other Protocols'' in section
III.A.3 of the preamble.
---------------------------------------------------------------------------
\1\ XDR stands for Cross-Enterprise Document Reliable
Interchange. XDM stands for Cross-Enterprise Document Media
Interchange.
---------------------------------------------------------------------------
We refer readers to section III.B.1 for a more detailed discussion
of the proposed 2015 Edition Base EHR definition.
b. CEHRT Definition
We propose to remove the Certified EHR Technology (CEHRT)
definition from Sec. 170.102 for the following reasons. The CEHRT
definition has always been defined in a manner that supports the EHR
Incentive Programs. As such, the CEHRT definition would more
appropriately reside solely within the EHR Incentive Programs
regulations. This would also be consistent with our approach in this
proposed rule to make the ONC Health IT Certification Program more open
and accessible to other types of health IT beyond EHR technology and
for health IT that supports care and practice settings beyond those
included in the EHR Incentive Programs. Further, this approach should
add administrative simplicity in that regulatory provisions, which EHR
Incentive Programs participants must meet (e.g., the CEHRT definition),
would be defined within the context of rulemakings for those programs.
We understand that the CEHRT definition proposed by CMS would continue
to include the Base EHR definition(s) defined by ONC, including the
2015 Edition Base EHR definition proposed in this proposed rule. We
also refer readers to Table 2 (``2015 Edition Proposed Certification
Criteria Associated with the EHR Incentive Programs Stage 3'') found in
section III.A.3 of this preamble. Table 2 crosswalks proposed 2015
Edition certification criteria with the proposed CEHRT definition and
proposed EHR Incentive Programs Stage 3 objectives.
c. Common Clinical Data Set
We propose to revise the ``Common MU Data Set'' definition in Sec.
170.102. We propose to change the name to ``Common Clinical Data Set,''
which aligns with our approach throughout this proposed rule to make
the ONC Health IT Certification Program more open and accessible to
other types of health IT beyond EHR technology and for health IT that
supports care and practice settings beyond those included in the EHR
Incentive Programs. We also propose to change references to the
``Common MU Data Set'' in the 2014 Edition (Sec. 170.314) to ``Common
Clinical Data Set.''
We propose to revise the definition to account for the new and
updated standards and code sets we propose to adopt in this proposed
rule that would improve and advance interoperability through the
exchange of the Common Clinical Data Set. We also propose to revise the
definition to support patient safety through clearly referenced data
elements and the inclusion of new patient data. These proposed
revisions would not change the standards, codes sets, and data
requirements specified in the Common Clinical Data Set for 2014 Edition
certification. They would only apply to health IT certified to the 2015
Edition Health IT certification criteria that reference the Common
Clinical Data Set.
3. The ONC Health IT Certification Program and Health IT Module
We propose to change the name of the ONC HIT Certification Program
to the ``ONC Health IT Certification Program'' (referred to as the
``ONC Health IT Certification Program'' throughout this proposed rule).
We also propose to modify the ONC Health IT Certification Program in
ways that would further open access to other types of health IT beyond
EHR technology and for health IT that supports care and practice
settings beyond the ambulatory and inpatient settings. These
modifications would also serve to support other public and private
programs that may reference the use of health IT certified under the
ONC Health IT Certification Program. When we established the
certification
[[Page 16807]]
program (76 FR 1294), we stated our initial focus would be on EHR
technology and supporting the EHR Incentive Programs, which focus on
the ambulatory setting and inpatient setting. Our proposals in this
proposed rule would permit other types of health IT (e.g., laboratory
information systems (LISs)), and technology implemented by health
information service providers (HISPs) and health information exchanges
(HIEs)) to receive appropriate attribution and not be referenced by a
certificate with ``EHR'' in it. Our proposals also support health IT
certification for other care and practice settings such as long-term
post-acute care (LTPAC), behavioral health, and pediatrics. Further,
the proposals in this rule would make it simpler for certification
criteria and certified health IT to be referenced by other HHS programs
(e.g., Medicaid and Medicare payment programs and various grant
programs), other public programs, and private entities and
associations.
As part of our approach to evolve the ONC Health IT Certification
Program, we have replaced prior rulemaking use of ``EHR'' and ``EHR
technology'' with ``health IT.'' The term health IT is reflective of
the scope of ONC's authority under the Public Health Service Act (Sec.
3000(5) as ``health information technology'' is so defined), and
represents a broad range of technology, including EHR technology. It
also more properly represents some of the technology, as noted above,
that has been previously certified to editions of certification
criteria under the ONC Health IT Certification Program and may be
certified to the proposed 2015 Edition in the future. Similarly, to
make the ONC Health IT Certification Program more open and accessible,
we propose to rename the EHR Module as ``Health IT Module'' and will
use this term throughout the proposed rule.
We propose not to require ONC-Authorized Certification Bodies
(ACBs) to certify all Health IT Modules to the 2015 Edition
``meaningful use measurement'' certification criteria (Sec.
170.315(g)(1) ``automated numerator recording'' and Sec. 170.315(g)(2)
``automated measure calculation''). We note that CMS has proposed to
include the 2015 Edition ``meaningful use measurement'' certification
criteria in the CEHRT definition as a unique program requirement for
the EHR Incentive Programs.
We propose a new, simpler, straight-forward approach to privacy and
security certification requirements for Health IT Modules certified to
the 2015 Edition. In essence, we identify the privacy and security
certification criteria that would be applicable to a Health IT Module
presented for certification based on the other capabilities included in
the Health IT Module and for which certification is sought. Under the
proposed approach, a health IT developer would know exactly what it
needed to do in order to get its Health IT Module certified and a
purchaser of a Health IT Module would know exactly what privacy and
security functionality against which the Health IT Module had to be
tested in order to be certified.
We propose new and revised principles of proper conduct (PoPC) for
ONC-ACBs. We propose to require ONC-ACBs to report an expanded set of
information to ONC for inclusion in the open data file that would make
up the Certified Health IT Product List (CHPL). We propose to revise
the PoPC in order to provide for more meaningful disclosure of certain
types of costs and limitations that could interfere with the ability of
users to implement certified health IT in a manner consistent with its
certification. We propose that ONC-ACBs retain records longer and
consistent with industry standards. We propose to require that ONC-ACBs
obtain a record of all adaptations and updates, including changes to
user-facing aspects, made to certified health IT, on a monthly basis
each calendar year. We propose to require that ONC-ACBs report to the
National Coordinator complaints received on certified health IT. We
propose to adopt new requirements for ``in-the-field'' surveillance
under the ONC Health IT Certification Program that would build on ONC-
ACBs' existing surveillance responsibilities by specifying requirements
and procedures for in-the-field surveillance. We believe these proposed
new and revised PoPC would promote greater transparency and
accountability for the ONC Health IT Certification Program. We also
include a request for comment on the potential ``decertification'' of
health IT that proactively blocks the sharing of information.
C. Costs and Benefits
Our estimates indicate that this proposed rule is an economically
significant rule as its overall costs for health IT developers may be
greater than $100 million in at least one year. We have, therefore,
projected the costs and benefits of the proposed rule. The estimated
costs expected to be incurred by health IT developers to develop and
prepare health IT to be tested and certified in accordance with the
2015 Edition health IT certification criteria (and the standards and
implementation specifications they include) are represented in monetary
terms in Table 1 below. We note that this proposed rule does not impose
the costs cited as compliance costs, but rather as investments which
health IT developers voluntarily take on and expect to recover with an
appropriate rate of return.
The dollar amounts expressed in Table 1 are expressed in 2013
dollars.
Table 1--Distributed Total Development and Preparation Costs for Health IT Developers (4-Year Period)--Totals
Rounded
----------------------------------------------------------------------------------------------------------------
Total high Total average
Year Ratio (%) Total low cost cost estimate cost estimate
estimate ($M) ($M) ($M)
----------------------------------------------------------------------------------------------------------------
2015............................................ 25 49.36 101.80 75.58
2016............................................ 30 59.23 122.16 90.70
2017............................................ 30 59.23 122.16 90.70
2018............................................ 15 29.61 61.08 45.35
---------------------------------------------------------------
4-Year Totals............................... .............. 197.43 407.20 302.32
----------------------------------------------------------------------------------------------------------------
We believe that there will be several significant benefits that may
arise from this proposed rule for patients, health care providers, and
health IT developers. The 2015 Edition continues to improve health IT
interoperability through the adoption of new and updated standards and
implementation specifications. For example, many
[[Page 16808]]
proposed certification criteria include standards and implementation
specifications for interoperability that directly support the EHR
Incentive Programs, which include objectives and measures for the
interoperable exchange of health information and for providing patients
electronic access to their health information in structured formats. In
addition, proposed certification criteria that support the collection
of patient data that could be used to address health disparities would
not only benefit patients, but the entire health care delivery system
through improved quality of care. The 2015 Edition also supports
usability and patient safety through new and enhanced certification
requirements for health IT.
Our proposals to make the ONC Health IT Certification Program open
and accessible to more types of health IT and for health IT that
supports a variety of care and practice settings should benefit health
IT developers, providers practicing in other care/practice settings,
and consumers through the availability and use of certified health IT
that includes capabilities that promote interoperability and enhanced
functionality.
II. Background
A. Statutory Basis
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 (the Recovery Act)
(Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act
amended the Public Health Service Act (PHSA) and created ``Title XXX--
Health Information Technology and Quality'' (Title XXX) to improve
health care quality, safety, and efficiency through the promotion of
HIT and electronic health information exchange.
1. Standards, Implementation Specifications, and Certification Criteria
The HITECH Act established two new federal advisory committees, the
Health IT Policy Committee (HITPC) and the Health IT Standards
Committee (HITSC) (sections 3002 and 3003 of the PHSA, respectively).
Each is responsible for advising the National Coordinator for Health
Information Technology (National Coordinator) on different aspects of
standards, implementation specifications, and certification criteria.
The HITPC is responsible for, among other duties, recommending
priorities for the development, harmonization, and recognition of
standards, implementation specifications, and certification criteria.
Main responsibilities of the HITSC include recommending standards,
implementation specifications, and certification criteria for adoption
by the Secretary under section 3004 of the PHSA, consistent with the
ONC-coordinated Federal Health IT Strategic Plan.
Section 3004 of the PHSA identifies a process for the adoption of
health IT standards, implementation specifications, and certification
criteria and authorizes 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 under section 3001(c) and
subsequently determine whether to propose the adoption of any grouping
of such standards, implementation specifications, or certification
criteria. The Secretary is required to publish all determinations in
the Federal Register.
Section 3004(b)(3) of the PHSA titled, Subsequent Standards
Activity, provides that the Secretary shall adopt additional standards,
implementation specifications, and certification criteria as necessary
and consistent with the schedule published by the HITSC. We consider
this provision in the broader context of the HITECH Act to grant the
Secretary the authority and discretion to adopt standards,
implementation specifications, and certification criteria that have
been recommended by the HITSC and endorsed by the National Coordinator,
as well as other appropriate and necessary health IT standards,
implementation specifications, and certification criteria. Throughout
this process, the Secretary intends to continue to seek the insights
and recommendations of the HITSC.
2. Health IT Certification Programs
Section 3001(c)(5) of the PHSA provides the National Coordinator
with the authority to establish a certification program or programs for
the voluntary certification of health IT. Specifically, section
3001(c)(5)(A) specifies that the National Coordinator, in consultation
with the Director of the National Institute of Standards and
Technology, shall keep or recognize a program or programs for the
voluntary certification of health information technology as being in
compliance with applicable certification criteria adopted under this
subtitle (i.e., certification criteria adopted by the Secretary under
section 3004 of the PHSA).
The certification program(s) must also include, as appropriate,
testing of the technology in accordance with section 13201(b) of the
[HITECH] Act. Overall, section 13201(b) of the HITECH Act requires that
with respect to the development of standards and implementation
specifications, the Director of the National Institute of Standards and
Technology (NIST), in coordination with the HITSC, shall support the
establishment of a conformance testing infrastructure, including the
development of technical test beds. The HITECH Act also indicates that
the development of this conformance testing infrastructure may include
a program to accredit independent, non-Federal laboratories to perform
testing.
B. Regulatory History
1. Standards, Implementation Specifications, and Certification Criteria
Rules
The Secretary issued an interim final rule with request for
comments titled, ``Health Information Technology: Initial Set of
Standards, Implementation Specifications, and Certification Criteria
for Electronic Health Record Technology'' (75 FR 2014, Jan. 13, 2010)
(the ``S&CC January 2010 interim final rule''), which adopted an
initial set of standards, implementation specifications, and
certification criteria. After consideration of the public comments
received on the S&CC January 2010 interim final rule, a final rule was
issued to complete the adoption of the initial set of standards,
implementation specifications, and certification criteria and realign
them with the final objectives and measures established for the EHR
Incentive Programs Stage 1 (formally titled: Health Information
Technology: Initial Set of Standards, Implementation Specifications,
and Certification Criteria for Electronic Health Record Technology;
Final Rule, (75 FR 44590, July 28, 2010) and referred to as the ``2011
Edition final rule''). The 2011 Edition final rule also established the
first version of the Certified EHR Technology (CEHRT) definition.
Subsequent to the 2011 Edition final rule (October 13, 2010), we issued
an interim final rule with a request for comment to remove certain
implementation specifications related to public health surveillance
that had been previously adopted in the 2011 Edition final rule (75 FR
62686).
The standards, implementation specifications, and certification
criteria
[[Page 16809]]
adopted by the Secretary in the 2011 Edition final rule established the
capabilities that CEHRT must include in order to, at a minimum, support
the achievement of EHR Incentive Programs Stage 1 by EPs, eligible
hospitals, and CAHs under the EHR Incentive Programs Stage 1 final rule
(the ``EHR Incentive Programs Stage 1 final rule'') (see 75 FR 44314
for more information about meaningful use and the Stage 1
requirements).
The Secretary issued a proposed rule with request for comments
titled ``Health Information Technology: Standards, Implementation
Specifications, and Certification Criteria for Electronic Health Record
Technology, 2014 Edition; Revisions to the Permanent Certification
Program for Health Information Technology'' (77 FR 13832, March 7,
2012) (the ``2014 Edition proposed rule''), which proposed new and
revised standards, implementation specifications, and certification
criteria. After consideration of the public comments received on the
2014 Edition proposed rule, a final rule was issued to adopt the 2014
Edition set of standards, implementation specifications, and
certification criteria and realign them with the final objectives and
measures established for the EHR Incentive Programs Stage 2 as well as
Stage 1 revisions (Health Information Technology: Standards,
Implementation Specifications, and Certification Criteria for
Electronic Health Record Technology, 2014 Edition; Revisions to the
Permanent Certification Program for Health Information Technology (77
FR 54163, Sept. 4, 2012) (the ``2014 Edition final rule''). The
standards, implementation specifications, and certification criteria
adopted by the Secretary in the 2014 Edition final rule established the
capabilities that CEHRT must include in order to, at a minimum, support
the achievement of the EHR Incentive Programs Stage 2 by EPs, eligible
hospitals, and CAHs under the EHR Incentive Programs Stage 2 final rule
(the ``EHR Incentive Programs Stage 2 final rule'') (see 77 FR 53968
for more information about the EHR Incentive Programs Stage 2
requirements).
On December 7, 2012, an interim final rule with a request for
comment was jointly issued and published by ONC and CMS to update
certain standards that had been previously adopted in the 2014 Edition
final rule. The interim final rule also revised the EHR Incentive
Programs by adding an alternative measure for the Stage 2 objective for
hospitals to provide structured electronic laboratory results to
ambulatory providers, corrected the regulation text for the measures
associated with the objective for hospitals to provide patients the
ability to view online, download, and transmit information about a
hospital admission, and made the case number threshold exemption policy
for clinical quality measure (CQM) reporting applicable for eligible
hospitals and CAHs beginning with FY 2013. The rule also provided
notice of CMS's intent to issue technical corrections to the electronic
specifications for CQMs released on October 25, 2012 (77 FR 72985). On
September 4, 2014, a final rule (Medicare and Medicaid Programs;
Modifications to the Medicare and Medicaid Electronic Health Record
(EHR) Incentive Program for 2014 and Other Changes to the EHR Incentive
Program; and Health Information Technology: Revisions to the Certified
EHR Technology Definition and EHR Certification Changes Related to
Standards; Final Rule) (79 FR 52910) was published adopting these
proposals.
On November 4, 2013, the Secretary published an interim final rule
with a request for comment, 2014 Edition Electronic Health Record
Certification Criteria: Revision to the Definition of ``Common
Meaningful Use (MU) Data Set'' (78 FR 65884), to make a minor revision
to the Common MU Data Set definition. This revision was intended to
allow more flexibility with respect to the representation of dental
procedures data for EHR technology testing and certification.
On February 26, 2014, the Secretary published a proposed rule
titled ``Voluntary 2015 Edition Electronic Health Record (EHR)
Certification Criteria; Interoperability Updates and Regulatory
Improvements'' (79 FR 10880) (``Voluntary Edition proposed rule''). The
proposed rule proposed a voluntary edition of certification criteria
that was designed to enhance interoperability, promote innovation, and
incorporate ``bug fixes'' to improve upon the 2014 Edition. A
correction notice was published for the Voluntary Edition proposed rule
on March 19, 2014, entitled ``Voluntary 2015 Edition Electronic Health
Record (EHR) Certification Criteria; Interoperability Updates and
Regulatory Improvements; Correction'' (79 FR 15282). This correction
notice corrected the preamble text and gap certification table for four
certification criteria that were omitted from the list of certification
criteria eligible for gap certification for the 2015 Edition EHR
certification criteria. On September 11, 2014, a final rule was
published titled ``2014 Edition Release 2 Electronic Health Record
(EHR) Certification Criteria and the ONC HIT Certification Program;
Regulatory Flexibilities, Improvements, and Enhanced Health Information
Exchange'' (79 FR 54430) (``2014 Edition Release 2 final rule''). The
final rule adopted a small subset of the original proposals in the
Voluntary Edition proposed rule as optional and revised 2014 Edition
EHR certification criteria that provide flexibility, clarity, and
enhance health information exchange. It also finalized administrative
proposals (i.e., removal of regulatory text from the Code of Federal
Regulations (CFR)) and proposals for the ONC HIT Certification Program
that provide improvements.
On May 23, 2014, CMS and ONC jointly published the ``Medicare and
Medicaid Programs; Modifications to the Medicare and Medicaid
Electronic Health Record Incentive Programs for 2014; and Health
Information Technology: Revisions to the Certified EHR Technology
Definition'' proposed rule (79 FR 29732). The rule proposed to update
the EHR Incentive Programs Stage 2 and Stage 3 participation timeline.
It proposed to revise the CEHRT definition to permit the use of EHR
technology certified to the 2011 Edition to meet the CEHRT definition
for FY/CY 2014. It also proposed to allow EPs, eligible hospitals, and
CAHs that could not fully implement EHR technology certified to the
2014 Edition for an EHR reporting period in 2014 due to delays in the
availability of such technology to continue to use EHR technology
certified to the 2011 Edition or a combination of EHR technology
certified to the 2011 Edition and 2014 Edition for the EHR reporting
periods in CY 2014 and FY 2014. On September 4, 2014, a final rule
(``CEHRT Flexibility final rule'') was published (79 FR 52910) adopting
these proposals.
2. Medicare and Medicaid EHR Incentive Programs Rules
On January 13, 2010, CMS published the EHR Incentive Programs Stage
1 proposed rule (75 FR 1844). The rule proposed the criteria for Stage
1 of the EHR Incentive Programs and regulations associated with the
incentive payments made available under Division B, Title IV of the
HITECH Act. Subsequently, CMS published a final rule (75 FR 44314) for
Stage 1 and the EHR Incentive Programs on July 28, 2010, simultaneously
with the publication of the 2011 Edition final rule. The EHR Incentive
Programs Stage 1 final rule established the objectives, associated
measures, and other requirements that EPs, eligible hospitals, and CAHs
must satisfy to meet Stage 1.
On March 7, 2012, CMS published the EHR Incentive Programs Stage 2
[[Page 16810]]
proposed rule (77 FR 13698). Subsequently, CMS published a final rule
(77 FR 53968) for the EHR Incentive Programs on Sept. 4, 2012,
simultaneously with the publication of the 2014 Edition final rule. The
EHR Incentive Programs Stage 2 final rule established the objectives,
associated measures, and other requirements that EPs, eligible
hospitals, and CAHs must satisfy to meet Stage 2 as well as revised
some Stage 1 requirements.
As described above in Section II.B.1, ONC and CMS jointly issued an
interim final rule with a request for comment that was published on
December 7, 2012 and a final rule that published on September 4, 2014.
Also, as described above in Section II.B.1, ONC and CMS jointly issued
proposed and final rules that were published on May 23, 2014 and
September 4, 2014, respectively.
3. ONC Health IT Certification Program Rules
On March 10, 2010, ONC published a proposed rule (75 FR 11328)
titled, ``Proposed Establishment of Certification Programs for Health
Information Technology'' (the ``Certification Programs proposed
rule''). The rule proposed both a temporary and permanent certification
program for the purposes of testing and certifying HIT. It also
specified the processes the National Coordinator would follow to
authorize organizations to perform the certification of HIT. A final
rule establishing the temporary certification program was published on
June 24, 2010 (75 FR 36158) (``Temporary Certification Program final
rule'') and a final rule establishing the permanent certification
program was published on January 7, 2011 (76 FR 1262) (``the Permanent
Certification Program final rule'').
On May 31, 2011, ONC published a proposed rule (76 FR 31272) titled
``Permanent Certification Program for Health Information Technology;
Revisions to ONC-Approved Accreditor Processes.'' The rule proposed a
process for addressing instances where the ONC-Approved Accreditor
(ONC-AA) engaged in improper conduct or did not perform its
responsibilities under the permanent certification program, addressed
the status of ONC-Authorized Certification Bodies in instances where
there may be a change in the accreditation organization serving as the
ONC-AA, and clarified the responsibilities of the new ONC-AA. All these
proposals were finalized in a final rule published on November 25, 2011
(76 FR 72636).
The 2014 Edition final rule made changes to the permanent
certification program. The final rule adopted a proposal to change the
Permanent Certification Program's name to the ``ONC HIT Certification
Program,'' revised the process for permitting the use of newer versions
of ``minimum standard'' code sets, modified the certification processes
ONC-ACBs need to follow for certifying EHR Modules in a manner that
provides clear implementation direction and compliance with the new
certification criteria, and eliminated the certification requirement
that every EHR Module be certified to all the mandatory ``privacy and
security'' certification criteria.
The Voluntary Edition proposed rule included proposals that focused
on improving regulatory clarity, simplifying the certification of EHR
Modules that are designed for purposes other than meeting Meaningful
Use requirements, and discontinuing the use of the Complete EHR
definition. As noted above, we issued the 2014 Edition Release 2 final
rule to complete the rulemaking for the Voluntary Edition proposed
rule. The 2014 Edition Release 2 final rule discontinued the ``Complete
EHR'' certification concept beginning with the proposed 2015 Edition,
adopted an updated standard (ISO/IEC 17065) for the accreditation of
ONC-ACBs, and adopted the ``ONC Certified HIT'' certification and
design mark for required use by ONC-ACBs under the ONC Health IT
Certification Program.
III. Provisions of the Proposed Rule Affecting Standards,
Implementation Specifications, and Certification Criteria
A. 2015 Edition Health IT Certification Criteria
This rule proposes new, revised, and unchanged certification
criteria that would establish the capabilities and related standards
and implementation specifications for the certification of health IT,
including EHR technology. We refer to these new, revised, and unchanged
certification criteria as the ``2015 Edition health IT certification
criteria'' and propose to add this term and its definition to Sec.
170.102. As noted in the Executive Summary, we also refer to these
criteria as the ``2015 Edition'' in this preamble. We propose to codify
the 2015 Edition in Sec. 170.315 to set them apart from other editions
of certification criteria and make it easier for stakeholders to
quickly determine the certification criteria the 2015 Edition includes.
Health IT certified to these proposed certification criteria and
associated standards and implementation specifications could be
implemented as part of an EP's, eligible hospital's, or CAH's CEHRT and
used to demonstrate meaningful use (as identified in Table 2 below). We
note that Table 2 does not identify certification criteria that are
included in conditional certification requirements, such as privacy and
security, safety-enhanced design, and quality management system
certification criteria. We do, however, classify these types of
certification criteria as ``associated'' with the EHR Incentives
Programs Stage 3 for the purposes of the regulatory impact analysis we
performed for this proposed rule (see section VIII.B.1).
Health IT certified to the proposed certification criteria and
associated standards and implementation specifications could also be
used to meet other HHS program requirements (e.g., grant and contract
requirements) or referenced by private sector associations and
entities.
Table 2--2015 Edition Proposed Certification Criteria Associated With the EHR Incentive Programs Stage 3
----------------------------------------------------------------------------------------------------------------
Relationship to the
proposed CEHRT \2\
Proposed CFR citation Certification Proposed inclusion in 2015 definition and
criterion edition base EHR definition proposed stage 3
objectives
----------------------------------------------------------------------------------------------------------------
Sec. 170.315(a)(1)............... Computerized Provider Included \3\............... Objective 4.
Order Entry (CPOE)--
medications.
Sec. 170.315(a)(2)............... CPOE--laboratory...... Included \4\............... Objective 4.
Sec. 170.315(a)(3)............... CPOE--diagnostic Included \5\............... Objective 4.
imaging.
[[Page 16811]]
Sec. 170.315(a)(4)............... Drug-drug, Drug- Not included............... Objective 3.
allergy Interaction
Checks for CPOE.
Sec. 170.315(a)(5)............... Demographics.......... Included................... No additional
relationship beyond
the Base EHR
definition.
Sec. 170.315(a)(7)............... Problem List.......... Included................... No additional
relationship beyond
the Base EHR
definition.
Sec. 170.315(a)(8)............... Medication List....... Included................... No additional
relationship beyond
the Base EHR
definition.
Sec. 170.315(a)(9)............... Medication Allergy Included................... No additional
List. relationship beyond
the Base EHR
definition.
Sec. 170.315(a)(10).............. Clinical Decision Included................... Objective 3.
Support.
Sec. 170.315(a)(11).............. Drug-formulary and Not included............... Objective 2.
Preferred Drug List
Checks.
Sec. 170.315(a)(12).............. Smoking Status........ Included................... No additional
relationship beyond
the Base EHR
definition.
Sec. 170.315(a)(14).............. Family Health History. Not included............... CEHRT \6\.
Sec. 170.315(a)(15).............. Family Health History-- Not included............... CEHRT \7\.
pedigree.
Sec. 170.315(a)(17).............. Patient-specific Not included............... Objective 5.
Education Resources.
Sec. 170.315(a)(19).............. Patient Health Not included............... CEHRT
Information Capture. Objective 6.
Sec. 170.315(a)(20).............. Implantable Device Included................... No additional
List. relationship beyond
the Base EHR
definition.
Sec. 170.315(b)(1)............... Transitions of Care... Included................... Objective 7.
Sec. 170.315(b)(2)............... Clinical Information Not included............... Objective 7.
Reconciliation and
Incorporation.
Sec. 170.315(b)(3)............... Electronic Prescribing Not included............... Objective 2.
Sec. 170.315(b)(6)............... Data Portability...... Included................... No additional
relationship beyond
the Base EHR
definition.
Sec. 170.315(c)(1) \8\........... Clinical Quality Included................... CEHRT.
Measures--record and
export.
Sec. 170.315(e)(1)............... View, Download, and Not included............... Objective 5
Transmit to Third Objective 6.
Party.
Sec. 170.315(e)(2)............... Secure Messaging...... Not included............... Objective 6.
Sec. 170.315(f)(1)............... Transmission to Not included............... Objective 8.\9\
Immunization
Registries.
Sec. 170.315(f)(2)............... Transmission to Public Not included............... Objective 8.
Health Agencies--
syndromic
surveillance.
Sec. 170.315(f)(3)............... Transmission to Public Not included............... Objective 8.
Health Agencies--
reportable laboratory
tests and values/
results.
Sec. 170.315(f)(4)............... Transmission to Cancer Not included............... Objective 8.
Registries.
Sec. 170.315(f)(5)............... Transmission to Public Not included............... Objective 8.
Health Agencies--case
reporting.
Sec. 170.315(f)(6)............... Transmission to Public Not included............... Objective 8.
Health Agencies--
antimicrobial use and
resistance reporting.
Sec. 170.315(f)(7)............... Transmission to Public Not included............... Objective 8.
Health Agencies--
health care surveys.
Sec. 170.315(g)(1)............... Automated Numerator Not included............... CEHRT.
Recording.
Sec. 170.315(g)(2)............... Automated Measure Not included............... CEHRT.
Calculation.
Sec. 170.315(g)(7)............... Application Access to Included................... Objective 5
Common Clinical Data Objective 6.
Set.
Sec. 170.315(h)(1)............... Direct Project........ Included \10\.............. No additional
relationship beyond
the Base EHR
definition.
Sec. 170.315(h)(2)............... Direct Project, Edge Included \11\.............. No additional
Protocol, and XDR/XDM. relationship beyond
the Base EHR
definition.
----------------------------------------------------------------------------------------------------------------
\2\ CMS' CEHRT definition would include the criteria adopted in the Base EHR definition. For more details on the
CEHRT definition, please see the CMS EHR Incentive Programs proposed rule published elsewhere in this issue of
the Federal Register.
\3\ Technology needs to be certified to Sec. 170.315(a)(1), (a)(2), or (a)(3).
\4\ Technology needs to be certified to Sec. 170.315(a)(1), (a)(2), or (a)(3).
\5\ Technology needs to be certified to Sec. 170.315(a)(1), (a)(2), or (a)(3).
\6\ Technology needs to be certified to Sec. 170.315(a)(14) or (a)(15).
\7\ Technology needs to be certified to Sec. 170.315(a)(14) or (a)(15).
\8\ As discussed in the preamble for the ``clinical quality measures--report'' criterion, additional CQM
certification policy may be proposed in or with CMS payment rules in CY15. As such, additional CQM
certification criteria may be proposed for the Base EHR and/or CEHRT definitions.
\9\ For the public health certification criteria in Sec. 170.315(f), technology would only need to be
certified to those criteria that are required to meet the options the provider intends to report in order to
meet the proposed Objective 8: Public Health and Clinical Data Registry Reporting.
\10\ Technology needs to be certified to Sec. 170.315(h)(1) or (h)(2) to meet the proposed Base EHR
definition.
\11\ Technology needs to be certified to Sec. 170.315(h)(1) or (h)(2) to meet the proposed Base EHR
definition.
[[Page 16812]]
1. Applicability
Section 170.300 establishes the applicability of subpart C--
Certification Criteria for Health Information Technology. We propose to
revise paragraph (d) of Sec. 170.300 to add in a reference to Sec.
170.315 and revise the parenthetical in the paragraph to say ``i.e.,
apply to any health care setting'' instead of ``i.e., apply to both
ambulatory and inpatient settings.'' These proposed revisions would
clarify which specific capabilities within a certification criterion
included in Sec. 170.315 have general applicability (i.e., apply to
any health care setting) or apply only to an inpatient setting or an
ambulatory setting. The proposed revision to change the language of the
parenthetical aligns with our proposed approach to make the ONC Health
IT Certification Program more agnostic to health care settings and
accessible to health IT that supports care and practice settings beyond
the ambulatory and inpatient settings. We refer readers to section IV.B
of this preamble for a detailed discussion of our proposals to modify
the ONC Health IT Certification Program.
We note that, with the proposed 2015 Edition, we no longer label
certification criteria as either optional or ambulatory/inpatient (at
the second paragraph level). For example, the proposed 2015 Edition
certification criterion for electronic medication administration record
is simply ``electronic medication administration record'' instead of
``inpatient setting only--electronic medication administration
record.'' Similarly, the proposed 2015 Edition certification criterion
for ``accounting of disclosures'' is simply ``accounting of
disclosures'' instead of ``optional--accounting of disclosures.'' These
simplifications are possible given that, beginning with the 2015
Edition health IT certification criteria, ``Complete EHR''
certifications will no longer be issued (see 79 FR 54443-45).
Therefore, there is no longer a need to designate an entire
certification criterion in this manner. Again, this approach supports
our goal to make the ONC Health IT Certification Program more agnostic
to health care settings and accessible to health IT that supports care
and practice settings beyond the ambulatory and inpatient settings.
We propose to replace the term ``EHR technology'' in paragraphs
(d)(1) and (d)(2) with ``health IT'' to align with our proposed
approach to make the ONC Health IT Certification Program more clearly
open to the certification of all types of health IT. Again, we refer
readers to section IV.B of this preamble for a detail discussion of our
proposals to modify the ONC Health IT Certification Program.
2. Standards and Implementation Specifications
a. National Technology Transfer and Advancement Act
The National Technology Transfer and Advancement Act (NTTAA) of
1995 (15 U.S.C. Sec. 3701 et. seq.) and the Office of Management and
Budget (OMB) Circular A-119 \12\ require the use of, wherever
practical, technical standards that are developed or adopted by
voluntary consensus standards bodies to carry out policy objectives or
activities, with certain exceptions. The NTTAA and OMB Circular A-119
provide exceptions to selecting only standards developed or adopted by
voluntary consensus standards bodies, namely when doing so would be
inconsistent with applicable law or otherwise impractical. In this
proposed rule, we refer to voluntary consensus standards, except for:
---------------------------------------------------------------------------
\12\ http://www.whitehouse.gov/omb/circulars_a119.
---------------------------------------------------------------------------
The standards adopted in Sec. 170.202. (These standards
were developed by groups of industry stakeholders committed to
advancing the Direct Project,\13\ which included initiatives under the
Standards and Interoperability (S&I) Framework.\14\ These groups used
consensus processes similar to those used by other industry
stakeholders and voluntary consensus standards bodies.);
---------------------------------------------------------------------------
\13\ http://www.healthit.gov/policy-researchers-implementers/direct-project.
\14\ http://www.healthit.gov/policy-researchers-implementers/standards-interoperability-si-framework.
---------------------------------------------------------------------------
The standards we propose to adopt at Sec.
170.205(a)(5)(iii) and (iv) for electronic submission medical
documentation (esMD) (These standards were developed by groups of
industry stakeholders committed to advancing esMD,\15\ which included
initiatives under the Standards and Interoperability (S&I)
Framework.\16\ These groups used consensus processes similar to those
used by other industry stakeholders and voluntary consensus standards
bodies.);
---------------------------------------------------------------------------
\15\ http://wiki.siframework.org/esMD+-+Author+of+Record and
http://wiki.siframework.org/esMD+-+Provider+Profiles+Authentication.
\16\ http://www.healthit.gov/policy-researchers-implementers/standards-interoperability-si-framework.
---------------------------------------------------------------------------
The standards we propose to adopt at Sec. 170.205(d)(4)
and (e)(4) for reporting of syndromic surveillance and immunization
information to public health agencies, respectively (These standards go
through a process similar within the public health community to those
used by other industry stakeholders and voluntary consensus standards
bodies.);
The standard we propose to adopt at Sec. 170.207(f)(2)
for race and ethnicity; and
Certain standards related to the protection of electronic
health information adopted in Sec. 170.210.
We are aware of no voluntary consensus standard that would serve as
an alternative to these standards for the purposes that we have
identified in this proposed rule.
b. Compliance With Adopted Standards and Implementation Specifications
In accordance with Office of the Federal Register regulations
related to ``incorporation by reference,'' 1 CFR part 51, which we
follow when we adopt proposed standards and/or implementation
specifications in any subsequent final rule, the entire standard or
implementation specification document is deemed published in the
Federal Register when incorporated by reference therein with the
approval of the Director of the Federal Register. Once published,
compliance with the standard and implementation specification includes
the entire document unless we specify otherwise. For example, if we
adopted the HL7 Laboratory Orders Interface (LOI) implementation guide
(IG) proposed in this proposed rule, health IT certified to
certification criteria referencing this IG would need to demonstrate
compliance with all mandatory elements and requirements of the IG. If
an element of the IG is optional or permissive in any way, it would
remain that way for testing and certification unless we specified
otherwise in regulation. In such cases, the regulatory text would
preempt the permissiveness of the IG.
c. ``Reasonably Available'' to Interested Parties
The Office of the Federal Register has established new requirements
for materials (e.g., standards and implementation specifications) that
agencies propose to incorporate by reference in the Federal Register
(79 FR 66267; 1 CFR 51.5(a)). To comply with these requirements, in
section VI (``Incorporation by Reference'') of this preamble, we
provide summaries of, and uniform resource locators (URLs) to, the
standards and implementation specifications we propose to adopt and
subsequently incorporate by reference in the Federal Register. To note,
we also provide relevant information about
[[Page 16813]]
these standards and implementation specifications throughout this
section of the preamble (section III), including URLs.
d. ``Minimum Standards'' Code Sets
We propose to adopt newer versions of four previously adopted
minimum standards code sets in this proposed rule for the 2015 Edition.
These code sets are the September 2014 Release of the U.S. Edition of
SNOMED CT[supreg], LOINC[supreg] version 2.50, the February 2, 2015
monthly version of RxNorm, and the February 2, 2015 version of the CVX
code set. We also propose to adopt two new minimum standards code sets
(the National Drug Codes (NDC)--Vaccine Codes, updates through January
15, 2015 and the ``Race & Ethnicity--CDC'' code system in the PHIN
Vocabulary Access and Distribution System (VADS) Release 3.3.9 (June
17, 2011)). As we have previously articulated (77 FR 54170), the
adoption of newer versions improve interoperability and health IT
implementation, while creating little additional burden through the
inclusion of new codes. As many of these minimum standards code sets
are updated frequently throughout the year, we will consider whether it
may be more appropriate to adopt a version of a minimum standards code
set that is issued before we publish a final rule for this proposed
rule. In making such determination, as we have done with these proposed
versions of minimum standards code sets, we will give consideration to
whether it includes any new substantive requirements and its effect on
interoperability. If adopted, a newer version of a minimum standards
code set would serve as the baseline for certification. As with all
adopted minimum standards code sets, health IT can be certified to
newer versions of the adopted baseline version minimum standards code
sets for purposes of certification, unless the Secretary specifically
prohibits the use of a newer version (see Sec. 170.555 and 77 FR
54268).
e. Object Identifiers (OIDs) for Certain Code Systems
We are providing the following table of OIDs for certain code
systems to assist health IT developers in the proper identification and
exchange of health information coded to the vocabulary standards
proposed in this proposed rule.
------------------------------------------------------------------------
Code system OID Code system name
------------------------------------------------------------------------
2.16.840.1.113883.6.96................. IHTSDO SNOMED CT.[supreg]
2.16.840.1.113883.6.1.................. LOINC.[supreg]
2.16.840.1.113883.6.88................. RxNorm.
2.16.840.1.113883.12.292............... HL7 Standard Code Set CVX-
Vaccines Administered.
2.16.840.1.113883.6.69................. National Drug Code Directory.
2.16.840.1.113883.6.8.................. Unified Code of Units of
Measure (UCUM \17\).
2.16.840.1.113883.6.13................. Code on Dental Procedures and
Nomenclature (CDT).
2.16.840.1.113883.6.4.................. International Classification of
Diseases, 10th Revision,
Procedure Coding System (ICD-
10-PCS).
2.16.840.1.113883.6.238................ Race & Ethnicity--Centers for
Disease Control and Prevention
(CDC).
2.16.840.1.113883.6.316................ Tags for Identifying Languages--
Request for Comment (RFC) 5646
(preferred language).
------------------------------------------------------------------------
f. Subpart B--Standards and Implementation Specifications for Health
Information Technology
In Sec. 170.200, we propose to remove term ``EHR Modules'' and add
in its place ``Health IT Modules.'' In Sec. 170.210, we propose to
remove the term ``EHR technology'' and add in its place ``health IT.''
These proposals are consistent with our overall approach to this
rulemaking as discussed in the Executive Summary.
---------------------------------------------------------------------------
\17\ Copyright (copyright) 1998-2013, Regenstrief Institute,
Inc. and the UCUM Organization. All rights reserved.
---------------------------------------------------------------------------
3. Certification Criteria
We discuss the certification criteria that we propose to adopt as
the 2015 Edition below. In a header for each criterion, we specify
where the proposed certification criteria would be included in Sec.
170.315. We discuss each certification criterion in the chronological
order in which it would appear in the CFR. In other words, the preamble
that follows will discuss the proposed certification criteria in Sec.
170.315(a) first, then Sec. 170.315(b), and so on.
We identify the certification criteria as new, revised, or
unchanged in comparison to the 2014 Edition. In the 2014 Edition final
rule we gave meaning to the terms ``new,'' ``revised,'' and
``unchanged'' to both describe the differences between the 2014 Edition
certification criteria and the 2011 Edition certification criteria as
well as establish what certification criteria in the 2014 Edition were
eligible for gap certification (see 77 FR 54171, 54202, and 54248).
Given that beginning with the 2015 Edition ``Complete EHR''
certifications will no longer be issued (see also 79 FR 54443-45) and
that our proposals in this proposed rule to make the ONC Health IT
Certification Program more open and accessible to other health care/
practice settings, we propose to give new meaning to these terms for
the purpose of a gap certification analysis.
``New'' certification criteria are those that as a whole
only include capabilities never referenced in previously adopted
certification criteria editions and to which a Health IT Module
presented for certification to the 2015 Edition could have never
previously been certified. As a counter example, the splitting of a
2014 Edition certification criterion into two criteria as part of the
2015 Edition would not make those certification criteria ``new'' for
the purposes of a gap certification eligibility analysis.
``Revised'' certification criteria are those that include
within them capabilities referenced in a previously adopted edition of
certification criteria as well as changed or additional new
capabilities; and to which a Health IT Module presented for
certification to the 2015 Edition could not have been previously
certified to all of the included capabilities.
``Unchanged'' certification criteria would be
certification criteria that include the same capabilities as compared
to prior certification criteria of adopted editions; and to which a
Health IT Module presented for certification to the 2015 Edition could
have been previously certified to all of the included capabilities.
We explain the proposed certification criteria and provide
accompanying rationale for the proposed certification criteria,
including citing the recommendations of the HITPC and HITSC, where
appropriate. For 2015 Edition health IT certification criteria
[[Page 16814]]
that have been revised in comparison to their 2014 Edition
counterparts, we focus the discussion on any revisions and
clarifications in comparison to the 2014 Edition version of the
criteria. A revised 2015 Edition certification criterion would also
include all the other capabilities that were included in the 2014
Edition version. For example, we propose to adopt a 2015 Edition
``drug-drug, drug-allergy interaction checks for CPOE'' certification
criterion (Sec. 170.315(a)(4)) that is revised in comparison to the
2014 Edition ``drug-drug, drug-allergy interaction checks'' criterion
(Sec. 170.314(a)(2)). We only discuss clarifications (e.g., the
criterion name change) and revisions we propose as part of the 2015
Edition ``drug-drug, drug-allergy interaction checks for CPOE''
certification criterion. However, the 2015 Edition criterion also
includes all the other capabilities of the 2014 Edition ``drug-drug,
drug allergy interaction checks'' criterion. We refer readers to Sec.
170.315 of the proposed regulation text near the end of this document,
which specifies all the capabilities included in each proposed 2015
Edition certification criterion.
We include an appendix (Appendix A) to this proposed rule, which
provides a table with the following data for each proposed 2015 Edition
certification criterion, as applicable: (1) Proposed CFR citation; (2)
estimated development hours; (3) proposed privacy and security
certification requirements (approach 1); \18\ (4) conditional
certification requirements (Sec. 170.550); (5) gap certification
eligibility; (6) proposed inclusion in the 2015 Edition Base EHR
definition; and (7) relationship to proposed Stage 3 of the EHR
Incentive Programs, including the CEHRT definition.
---------------------------------------------------------------------------
\18\ Please see section IV.C.1 (``Privacy and Security'') for a
detailed discussion of approach 1.
---------------------------------------------------------------------------
We propose, and readers should interpret, that the following terms
used in the proposed 2015 Edition have the same meanings we adopted in
the 2014 Edition final rule (77 FR 54168-54169), in response to public
comment: ``user,'' ``record,'' ``change,'' ``access,'' ``incorporate,''
``create,'' and ``transmit,'' but apply to all health IT not just ``EHR
technology.'' For the term ``incorporate,'' we also direct readers to
the additional explanation we provided under the ``transitions of
care'' certification criterion (77 FR 54218) in the 2014 Edition final
rule and in the Voluntary Edition proposed rule (79 FR 10898). We
propose that the scope of a 2015 Edition certification criterion is the
same as the scope previously assigned to a 2014 Edition certification
criterion (for further explanation, see the discussion at 77 FR 54168).
That is, certification to proposed 2015 Edition health IT certification
criteria at Sec. 170.315 would occur at the second paragraph level of
the regulatory section and encompass all paragraph levels below the
second paragraph level. We also propose to continue to use the same
specific descriptions for the different types of ``data summaries''
established in the 2014 Edition final rule (77 FR 54170-54171) for the
proposed 2015 Edition health IT certification criteria (i.e., ``export
summary,'' ``transition of care/referral summary,'' ``ambulatory
summary,'' and ``inpatient summary.'')
As with the adoption of the 2011 and 2014 editions of certification
criteria (see the introductory text to Sec. Sec. 170.302, 170.304,
170.306, and 170.314), all capabilities mentioned in certification
criteria are expected to be performed electronically, unless otherwise
noted. Therefore, we no longer include ``electronically'' in
conjunction with each capability included in a certification criterion
proposed under Sec. 170.315 because the proposed introductory text to
Sec. 170.315 (which covers all the certification criteria included in
the section) clearly states that health IT must be able to
electronically perform the following capabilities in accordance with
all applicable standards and implementation specifications adopted in
the part.
Computerized Provider Order Entry
In the 2014 Edition Release 2 final rule, we adopted separate
computerized provider order entry (CPOE) certification criteria based
on the clinical purpose (i.e., medications, laboratory, and diagnostic
imaging) (79 FR 54435-36). We propose to take the same approach for the
2015 Edition and propose to adopt three certification criteria for
CPOE, as compared to a single criterion that would include combined
functionality for all three clinical purposes (e.g., Sec.
170.314(a)(1)).
We request comment on whether we should specify, for the purposes
of testing and certification to the 2015 Edition CPOE criteria, certain
data elements that a Health IT Module must be able to include in a
transmitted order. In particular, we request comment on whether a
Health IT Module should be able to include any or all of the following
data elements: secondary diagnosis codes; reason for order; and comment
fields entered by the ordering provider, if they are provided to the
ordering provider in their order entry screen. We also request comment
on whether there are any other data elements that a Health IT Module
should be able to include as part of an order for the purposes of
testing and certification. We clarify, however, that any specific data
requirements for a transmitted order that may be adopted in a final
rule would only apply in the absence of a standard for testing and
certification. As discussed below, we propose a laboratory order
standard for the ambulatory setting. If we were to adopt this standard
in a final rule, any potential required data elements for a transmitted
order adopted in response to this proposal would not be made applicable
to the ambulatory setting for the ``CPOE--laboratory'' certification
criterion.
Computerized Provider Order Entry--Medications
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(1) (Computerized provider order entry--medications)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition CPOE certification criterion
specific to medication ordering. This proposed criterion does not
reference any standards or implementation specifications and is
unchanged in comparison to the 2014 Edition CPOE--medications criterion
adopted at Sec. 170.314(a)(18).
Computerized Provider Order Entry--Laboratory
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(2) (Computerized provider order entry--laboratory)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition CPOE certification criterion
specific to laboratory ordering that is revised in comparison to the
CPOE--laboratory criterion adopted at Sec. 170.314(a)(19) as well as
Sec. 170.314(a)(1).
We propose to adopt and include in this criterion, for the
ambulatory setting, the HL7 Version 2.5.1 Implementation Guide: S&I
Framework Laboratory Orders (LOI) from EHR, Draft Standard for Trial
Use, Release 2--US Realm (``Release 2'').\19\ Due to the absence of a
consensus standard for the purpose of sending laboratory orders from
EHRs to laboratories, this standard was developed in conjunction with
laboratories representative of the industry, health IT developers, and
[[Page 16815]]
provider stakeholders through an open consensus-based process under the
Standards and Interoperability Framework (S&I Framework). Release 1 of
the standard was balloted and approved through HL7, a standards
developing organization. Release 2 is currently under ballot
reconciliation with HL7 and should be published in the next few months.
Release 2 would:
---------------------------------------------------------------------------
\19\ http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=922 and http://www.hl7.org/participate/onlineballoting.cfm?ref=nav#nonmember.
Access to the current draft of the LOI Release 2 IG is freely
available for review during the public comment period by
establishing an HL7 user account.
---------------------------------------------------------------------------
Implement common formats across US Realm IGs for
consistent reader experience (e.g., sequence of sections, formatting,
layout, and terminology);
Adopt HL7 version 2.8 fields developed to fill gaps
identified in the development of Release 1;
Include harmonized data type ``flavors'' for use across
the US Realm Lab IGs;
Introduce initial requirements for error reporting
conditions and severity (hard/soft errors) and system/application
acknowledgements;
Harmonize data element usage and cardinality requirements
with LOI Release 1, and the electronic Directory of Services (eDOS) IG;
Incorporate US Lab Realm value sets developed for clarity
and consistency across all laboratory IGs; and
Use a new publication method for value sets that allows
for precision usage at point of use and provides ``at a glance''
comprehensive usage at the field and component-level across all
laboratory IGs; and synced with value set activities (HL7, VSAC, etc.).
Overall, we propose to adopt Release 2 of the standard because it
addresses errors and ambiguities found in Release 1 and harmonizes
requirements with other laboratory standards we propose to adopt in
this proposed rule. Release 2 would also make implementation of the LOI
IG clearer and more consistent for health IT developers and
laboratories, as well as improve interoperability. We propose to adopt
Release 2 at Sec. 170.205(l)(1).
Commenters on the Voluntary Edition proposed rule noted that for
optimal interoperability we need to also adopt the most recent version
of the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory
Test Compendium Framework, Release 2, (also referred to as the
``electronic Directory of Services (eDOS) IG''), as it is the companion
IG to the LOI IG. We agree with the commenters' assessment and propose
to include the most recent version of the eDOS IG in this criterion for
certification to all health care settings (i.e., not confining it to
only the ambulatory setting) and adopt it at Sec. 170.205(l)(2). The
most recent version of the eDOS IG will be Release 2, Version 1.2,
which is scheduled to publish in the next few months. Release 2,
Version 1.2 is currently under ballot reconciliation.\20\ In general,
the eDOS IG provides requirements and guidance for the delivery of an
electronic Directory of Services (test compendium) from a laboratory
(compendium producer) to an EHR or other system (compendium consumer)
where it is used to produce electronic orders (LOI-conformant messages)
for laboratory tests. Version 1.2 of the eDOS IG addresses errors and
ambiguities in the prior version as well as harmonizes with Release 2
of the LOI IG.
---------------------------------------------------------------------------
\20\ http://www.hl7.org/participate/onlineballoting.cfm?ref=nav#nonmember. Access to the current draft
of the eDOS IG, Release 2, Version 1.2 is freely available for
review during the public comment period by establishing an HL7 user
account.
---------------------------------------------------------------------------
We also propose, for the purposes of certification, to require a
Health IT Module to be able to use, at a minimum, the version of
Logical Observation Identifiers Names and Codes (LOINC[supreg]) adopted
at Sec. 170.207(c)(3) (version 2.50) as the vocabulary standard for
laboratory orders. This is the most recent version of LOINC[supreg]. We
refer readers to section III.A.2.d (``Minimum Standards'' Code Sets)
for further discussion of our adoption of LOINC[supreg] as a minimum
standards code set and our proposal to adopt version 2.50, or
potentially a newer version if released before a subsequent final rule,
as the baseline for certification to the 2015 Edition.
We note that the LOI Release 2 IG requires the information for a
test requisition as specified in the Clinical Laboratory Improvement
Amendments (CLIA), 42 CFR 493.1241(c)(1) through (c)(8), to be included
in the content message. Therefore, inclusion of this standard for
certification may also facilitate laboratory compliance with CLIA.
Computerized Provider Order Entry--Diagnostic Imaging
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(3) (Computerized provider order entry--diagnostic
imaging)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition CPOE certification criterion
specific to diagnostic imaging. This proposed criterion does not
reference any standards or implementation specifications, and is
unchanged in comparison to the 2014 Edition CPOE--diagnostic imaging
criterion adopted at Sec. 170.314(a)(20). To note, we also propose to
adopt the title of ``diagnostic imaging,'' which is the title we gave
to the 2014 Edition version of this certification criterion in the 2014
Edition Release 2 final rule (79 FR 54436).
Drug-Drug, Drug-Allergy Interaction Checks for CPOE
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(4) (Drug-drug, drug-allergy interaction checks for
CPOE)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``drug-drug, drug-allergy
interaction checks for CPOE'' certification criterion that is revised
in comparison to the 2014 Edition ``drug-drug, drug-allergy interaction
checks'' criterion (Sec. 170.314(a)(2)). We propose to clarify that
the capabilities included in this criterion are focused on CPOE by
including ``for CPOE'' in the title of this criterion.
We also propose to include in this criterion the capabilities to
record user actions for drug-drug, drug-allergy interaction (DD/DAI)
interventions and to enable a user to view the actions taken for DD/DAI
interventions (also referred to as ``checks''). Specifically, we
propose that a Health IT Module must be able to record at least one
action taken and by whom in response to drug-drug or drug-allergy
interaction checks. To be certified to this criterion, a Health IT
Module (at a user's request) must also be able to generate either a
human readable display or human readable report of actions taken and by
whom in response to drug-drug or drug-allergy interaction checks.
We solicited comment in the Voluntary Edition proposed rule on
whether health IT should be able to track (which means ``record'' and
will be referred to as ``record'' throughout this preamble) provider
(referred to as ``user'' for the purposes of this proposed
certification criterion) actions for DD/DAI interventions, including
recording if and when the user viewed, accepted, declined, ignored,
overrode, or otherwise commented on the DD/DAI interventions. We
received comments that supported recording user actions for DD/DAI
interventions (79 FR 54449). We also received comments recommending
that we consider including recording user actions in response to CDS
interventions. We discuss those comments under the CDS certification
criterion in this section (III.A.3) of the preamble.
We believe that recording user actions for DD/DAI interventions
could assist with quality improvement and patient safety. While some
commenters expressed concern that functionality for recording user
actions would be
[[Page 16816]]
burdensome to develop, we believe the potential benefits of improved
care and reduced adverse events that can come from using such
functionality and being able to subsequently analyze user actions for
DD/DAI interventions outweighs the development burden. To provide
health IT developers with flexibility and the opportunity to innovate,
we have explicitly not specified the types of actions a Health IT
Module must be able to record to meet this criterion. Health IT
developers would need to simply demonstrate that their Health IT Module
can record at least one user action for DD/DAI checks. For example, a
Health IT Module could include the capability to record whether the
user viewed, accepted, declined, ignored, overrode, provided a
rationale or explanation for the action taken, took some other type of
action not listed here or otherwise commented on the DD/DAI check. We
solicit comment on whether we should focus this proposed requirement to
record at least one user action taken for DD/DAI interventions on a
subset of DD/DAI interventions, such as those of highest patient safety
concern, and what sources we should consider for defining this subset.
We note, however, that we do not intend with this proposed
requirement to infer a specific workflow or user interface in order to
achieve conformance to this criterion. While appropriate documentation
in accordance with clinical, safety, and system design best practices
for these DD/DAI interventions is beyond the scope of certification for
this criterion, we would encourage health IT developers to consider
these best practices in developing this functionality and attempt to
not interrupt a provider's workflow unnecessarily to meet this
criterion. This criterion also does not propose to establish the uses
for the ``user action'' information, whom should be able to view the
information, or who could adjust the capability. Further, based on
stakeholder feedback, there does not appear to be a consensus method or
standard for characterizing the severity of patient DD/DAI reactions.
Therefore, until the stakeholder community determines if there should
be a set of methods, standards, or clinical guidelines for determining
the severity of a patient DD/DAI reaction, we believe that users should
determine these definitions for their organization and/or setting.
While this proposed certification criterion focuses on DD/DAI
checking at the point when a user enters a computerized order, we
believe that there are instances when a user should be aware of a
patient's DD/DAI when new medications or medication allergies are
entered into the patient record. Therefore, we strongly encourage
health IT developers to build in functionality, including but not
limited to clinical decision support, that would inform a user of new
or updated DD/DAI when the medication or medication allergy lists are
updated. We also seek comment on whether we should include this
functionality in certification and whether this functionality should be
included in an existing certification criterion (e.g., medication list,
medication allergy list, clinical decision support) or a standalone
criterion.
Demographics
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(5) (Demographics)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``demographics'' certification
criterion that is revised as described below in comparison to the 2014
Edition certification criterion (Sec. 170.314(a)(3)).
Sex
We propose that, for certification (and testing) to this criterion,
health IT must be capable of recording sex in accordance with HL7
Version 3 (``AdministrativeGender'') and a nullFlavor value attributed
as follows: male (M); female (F); and unknown (UNK). This proposal
serves as another means of improving interoperability through the use
of consistent standards.
We propose in a later section of this rule that using HL7 Version 3
for recording sex would be required under the ``Common Clinical Data
Set'' definition for certification to the 2015 Edition. Please see
section III.B.3 ``Common Clinical Data Set'' of this preamble for
further discussion of this associated proposal.
Race and Ethnicity
We propose that, for certification (and testing) to this criterion,
a Health IT Module must be capable of recording each one of a patient's
races and ethnicities in accordance with, at a minimum, the ``Race &
Ethnicity--CDC'' code system in the PHIN Vocabulary Access and
Distribution System (VADS), Release 3.3.9.\21\ We also propose that a
Health IT Module must be able to aggregate each one of a patient's
races and ethnicities to the categories in the OMB standard for race
and ethnicity, which we previously adopted for the 2011 Edition and
2014 Edition ``demographics'' certification criteria.
---------------------------------------------------------------------------
\21\ https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238#.
---------------------------------------------------------------------------
As discussed in the 2014 Edition final rule (77 FR 54208), the OMB
standard for the classification of data on race and ethnicity requires
that the option for selecting one or more racial designations be
provided. The standard also permits the use of more than the minimum
standard categories for race and ethnicity, but requires that the data
can be ``rolled up'' or mapped to the minimum standard categories as
well as aggregated. The ``Race & Ethnicity--CDC'' code system in PHIN
VADS (at a minimum, Release 3.3.9) permits a much more granular
structured recording of a patient's race and ethnicity with its
inclusion of over 900 concepts for race and ethnicity. The recording
and exchange of patient race and ethnicity at such a granular level can
facilitate the accurate identification and analysis of health
disparities based on race and ethnicity. Further, the ``Race &
Ethnicity--CDC'' code system has a hierarchy that rolls up to the OMB
minimum categories for race and ethnicity and, thus, supports
aggregation and reporting using the OMB standard. Accordingly, we
propose the adoption and inclusion of both these standards in this
certification criterion as described.
For the purposes of testing and certification to this
``demographics'' criterion, we would test that a Health IT Module can
record each one of a patient's races and ethnicities using any of the
900 plus concepts in the ``Race & Ethnicity--CDC'' code system. We
would not, however, expect the user interface to include a drop-down
menu of all 900 plus ``Race & Ethnicity--CDC'' code system concepts for
race and ethnicity, as we believe doing so could have negative workflow
effects. Rather, we expect that health IT developers and health care
providers would work together to establish the appropriate
implementation given the care setting.
We refer readers to section III.A.2.d (``Minimum Standards'' Code
Sets) for further discussion of our proposal to adopt ``Race &
Ethnicity--CDC'' code system in PHIN VADS as a minimum standards code
set and Release 3.3.9, or potentially a newer version if released
before a subsequent final rule, as the baseline for certification to
the 2015 Edition.
We propose in a later section of this proposed rule that the ``Race
& Ethnicity--CDC'' code system in PHIN VADS (at a minimum, Release
3.3.9) and the OMB standard would become the race and ethnicity
standards under the ``Common Clinical Data Set'' definition for
certification to the 2015
[[Page 16817]]
Edition. Please see section III.B.3 ``Common Clinical Data Set'' of
this preamble for further discussion of this associated proposal.
Preferred Language
Based on specific HITSC recommendations from 2011, we adopted ISO
639-2 constrained by ISO 639-1 for recording preferred language in the
2014 Edition ``demographics'' certification criterion (77 FR
54208).\22\ More specifically, this means that technology is required
to be capable of using the alpha-3 codes of ISO 639-2 to represent the
corresponding alpha-2 code in ISO-639-1. To provide further clarity, we
issued FAQ 27 \23\ in which we stated that where both a bibliographic
code and terminology code are present for a required ISO 639-2
language, technology is expected to be capable of representing the
language in accordance with the (T) terminology codes (ISO 639-2/T) for
the purposes of certification. After we issued FAQ 27, we issued FAQ 43
\24\ in which we acknowledge that our constrained approach to the use
of ISO 639-2 unintentionally excluded multiple languages that are
currently in use, such as sign language and Hmong. Additionally, ISO
639-2 is meant to support written languages, which may not be the
language with which patients instinctively respond when asked for their
preferred language.
---------------------------------------------------------------------------
\22\ http://www.loc.gov/standards/iso639-2/php/code_list.php.
\23\ http://www.healthit.gov/policy-researchers-implementers/27-question-10-12-027.
\24\ http://www.healthit.gov/policy-researchers-implementers/43-question-11-13-043.
---------------------------------------------------------------------------
To improve the situation described above, we propose to adopt the
Internet Engineering Task Force (IETF) Request for Comments (RFC) 5646
\25\ standard for preferred language. RFC 5646 entitled ``Tags for
Identifying Languages, September 2009'' is the coding system that is
commonly used to encode languages on the web and is the most current
RFC for this purpose and listed as a ``best current practice.'' \26\
The first part of the code relies on the shortest ISO-639 code for the
language. That means a 2-character code if the language is specified in
ISO 639-1 or a 3-character code from ISO 639-2 or -3, if the language
is only listed in one of those two ISO standards. We are also aware
that RFC 5646 supports dialects.
---------------------------------------------------------------------------
\25\ http://www.rfc-editor.org/info/rfc5646.
\26\ http://www.rfc-editor.org/info/rfc5646.
---------------------------------------------------------------------------
After consideration of comments we received on the Voluntary
Edition proposed rule (79 FR 54450) and further research, we believe
that RFC 5646 is the most appropriate standard to support preferred
language interoperability. It is our understanding that this standard
is compatible with the C-CDA Release 2.0 and that other preferred
language standards in use today can be efficiently mapped to it, such
as ISO 639-1, 639-2, and 639-3. Therefore, for the purposes of testing
and certification to this ``demographics'' criterion, we would test
that a Health IT Module can record a patient's preferred language using
any of the codes in RFC 5646.
We emphasize that this requirement would apply to a Health IT
Module presented for certification and not health care providers. In
other words, a Health IT Module certified to this criterion would need
to support the recording of preferred language in RFC 5646 and should
in no way be interpreted or imply the way in which health care
providers use the capability to record preferred language or the
preferred language values they are presented with to select a patient's
preferred language. For example, we would not expect the user interface
to include a drop-down menu of all RFC 5646 codes for language, as we
believe doing so could have negative workflow effects. Rather, we
expect that health IT developers and health care providers would work
together to establish the appropriate implementation given the care
setting.
We propose in a later section of this proposed rule that RFC 5646
would also become the preferred language standard under the ``Common
Clinical Data Set'' definition for certification to the 2015 Edition.
Please see section III.B.3 (``Common Clinical Data Set'') of this
preamble for further discussion of this associated proposal.
Preliminary Cause of Death and Date of Death
We propose to include in the 2015 Edition the capability to enable
a user to electronically record, change, and access the ``date of
death'' as a required capability that EHR technology designed for the
inpatient setting must demonstrate. We previously included this
capability as part of the 2011 Edition ``demographics'' certification
criterion and inadvertently omitted it from the 2014 Edition. While we
heard from commenters in response to the Voluntary Edition proposed
rule that they were unaware of any developer removing this capability,
we believe it is appropriate to specifically include this capability in
the 2015 Edition criterion for testing and certification purposes and
to align with the data required by the Meaningful Use criteria of the
EHR Incentive Programs. To note, this functionality would be in
addition to the inclusion in the 2015 Edition ``demographics''
certification criterion of the same capability to enable a user to
electronically record, change, and access ``preliminary cause of
death'' in case of mortality, as is included in the 2014 Edition
``demographics'' certification criterion.
Vital Signs, Body Mass Index (BMI), and Growth Charts
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(6) (Vital signs, body mass index, and growth charts)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``vital signs, BMI, and growth
charts'' certification criterion that is revised in comparison to the
2014 Edition ``vital signs, BMI, and growth charts'' criterion (Sec.
170.314(a)(4)). Specifically, we propose to: 1) Expand the types of
vital signs for recording; 2) require that each type of vital sign have
a specific LOINC[supreg] code attributed to it; 3) that The Unified
Code of Units of Measure, Revision 1.9, October 23, 2013 (``UCUM
Version 1.9'') \27\ be used to record vital sign measurements; and 4)
that certain metadata accompany each vital sign, including date, time,
and measuring- or authoring-type source.
---------------------------------------------------------------------------
\27\ http://unitsofmeasure.org/trac/.
---------------------------------------------------------------------------
Proposed Approach for Vital Signs
In the Voluntary Edition proposed rule (79 FR 10889-10890), we
solicited comment on whether we should require health IT to record
vital signs in standardized vocabularies. We solicited comments on
whether we should require that vital signs be recorded in standardized
vocabularies natively within the health IT system or only during
transmission. We also solicited comment on whether we should require
vital signs be recorded with specific metadata for contextual purposes.
Many commenters recommended that the industry should standardize
how vital signs are represented and collected. To this end, we are
aware that several stakeholder groups are working to define unique,
unambiguous representations/definitions for clinical concepts along
with structured metadata that together provide improved context for the
system to interpret information, including vital signs. This approach
can help increase data standardization at a granular level so that
clinical elements and associated values/findings can be consistently
represented and exchanged. For example, blood pressure is represented
in current systems using a variety of formats, which creates
[[Page 16818]]
significant challenges to aggregate, compare, and exchange data across
systems. This occurs despite the numeric nature of blood pressure,
resulting in costly and time-consuming manual translation to integrate
this data across systems.
Some commenters supported requiring standardized vocabularies for
vital signs during data exchange rather than natively within the health
IT system. While we agree that data should be exchanged in a standard
way, we also believe that the granularity necessary to unambiguously
represent this data should be implemented within health IT systems so
that data is captured with the same level of specificity to enable
consistent and reliable interpretation by other data users and
receivers without requiring mapping. Thus, we propose that health IT
demonstrate it is able to record vital signs data natively as specified
below. Overall, these proposals reflect our interest in ensuring that
the data a user enters into a health IT system is semantically and
syntactically identical to the information coming out of the system and
being exchanged. We believe this would increase the confidence that the
data exchanged is what the provider intended.
The 2014 Edition ``vital signs'' certification criterion requires
health IT to enable a user to electronically record, change, and access
a patient's height/length, weight, and blood pressure. We propose to
include BMI, heart rate, respiratory rate, temperature, oxygen
saturation in arterial blood by pulse oximetry, and mean blood pressure
as we understand that these vital signs are commonly captured or
calculated (i.e., BMI) in the routine course of clinical encounters
across a wide variety of both inpatient and ambulatory settings. We
also propose to further specify that health IT would need to be able to
record diastolic and systolic blood pressure as separate vital signs
rather than ``blood pressure'' (unspecified) as a single vital sign. We
clarify that this list of vital signs is not intended to be
comprehensive. Rather, these listed vital signs indicate our interest
in a more specific approach to recording and exchanging vital signs
data that could promote unambiguous interpretation. These vital sign
concepts derive from the C-CDA standard and the Public Health
Information Network Vocabulary Access and Distribution System value set
for vital sign result types \28\ (2.16.840.1.113883.3.88.12.80.62),
which was developed by the Health IT Standards Panel.\29\ Therefore, we
believe the health care community has experience with collecting these
vital sign concepts because they have been defined for some time as
part of previous collaborative stakeholder work.
---------------------------------------------------------------------------
\28\ https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.88.12.80.62.
\29\ The Health IT Standards Panel was established in 2005 as a
strategic public-private partnership in contract with the U.S.
Department of Health and Human Services to achieve a widely accepted
and useful set of standards to enable and support widespread
interoperability among healthcare software applications. The Health
IT Standards Panel's contract with HHS concluded on April 30, 2010.
http://www.hitsp.org/.
---------------------------------------------------------------------------
We propose to require that a Health IT Module be able to attribute
a specific LOINC[supreg] code to each type of vital sign using the
following identifiers:
``Systolic blood pressure'' with LOINC[supreg] code 8480-
6;
``Diastolic blood pressure'' with LOINC[supreg] code 8462-
4;
``Body height'' with LOINC[supreg] code 8302-2;
``Body weight measured'' with LOINC[supreg] code 3141-9;
``Heart rate'' with LOINC[supreg] code 8867-4;
``Respiratory rate'' with LOINC[supreg] code 9279-1;
``Body temperature'' with LOINC[supreg] code 8310-5;
``Oxygen saturation in arterial blood by pulse oximetry''
with LOINC[supreg] code 59408-5;
``Body mass index (BMI) [Ratio]'' with LOINC[supreg] code
39156-5; and
``Mean blood pressure'' with LOINC[supreg] code 8478-0.
We understand that the industry is commonly identifying these vital
signs using LOINC[supreg] codes today.
We also propose to require that a Health IT Module enable a user to
record these vital signs with at least the following metadata:
date and time of vital sign measurement or end time of
vital sign measurement with optional certification in accordance with
the clock synchronization standard adopted at Sec. 170.210(g); and
the measuring- or authoring-type source of the vital sign
measurement (such as the user who documented the vital sign or the
medical device that was used to measure the vital sign).
In some cases, the provider documenting the vital sign may record
the date and time of vital sign measurement manually and enter the data
into a health IT system at a later time; therefore, it would not be
necessary to use the clock synchronization standard. However, use of
the clock synchronization standard may be useful for situations where
the vital sign data comes from a device and should be synchronized with
the health IT system.
For ``oxygen saturation in arterial blood by pulse oximetry,'' we
propose that a Health IT Module enable a user to record ``inhaled
oxygen concentration'' with LOINC[supreg] code 3150-0 as metadata
associated with the vital sign. We understand that ``inhaled oxygen
concentration'' is frequently provided to assist with interpretation of
the ``oxygen saturation in arterial blood by pulse oximetry'' value.
For all units of measure associated with a vital sign value, we
propose to require that health IT be able to record an applicable unit
of measure in accordance with UCUM Version 1.9 (e.g., the UCUM unit
``mm[Hg]'' for systolic blood pressure; e.g., the UCUM unit
``[lb_av],'' ``g,'' ``kg,'' or ``[oz_av]'' for body weight). We note
that LOINC provides a translation table \30\ that enumerates the UCUM
syntax for a subset of UCUM codes that are commonly used in health IT
that may be a useful reference for stakeholders.
---------------------------------------------------------------------------
\30\ https://loinc.org/downloads/usage/units.
---------------------------------------------------------------------------
Proposed ``Optional'' Pediatric Vital Signs
We propose to offer optional certification for health IT to be able
to electronically record, change, and access:
Body mass index (BMI) [Percentile] per age and sex (with
LOINC[supreg] code 59576-9) for youth 2-20 years of age; and
Weight for length per age and sex (with LOINC[supreg] code
to be established in a newer version of LOINC[supreg] prior to the
publication of a subsequent final rule) and/or Head occipital-frontal
circumference by tape measure (with LOINC[supreg] code 8287-5) for
infants less than 3 years of age.
We propose to require that a Health IT Module enable each optional
vital sign to be recorded with an applicable unit of measure in
accordance with UCUM Version 1.9. CDC recommends the collection of
these anthropomorphic indices for youth 2-20 years of age and infants
less than 3 years of age, respectively, as part of best care
practices.\31\
---------------------------------------------------------------------------
\31\ http://www.cdc.gov/growthcharts/clinical_charts.htm#Set1
and http://www.cdc.gov/growthcharts/clinical_charts.htm#Set2.
---------------------------------------------------------------------------
A Health IT Module certified to the ``BMI percentile per age and
sex,'' ``weight for length per age and sex,'' or ``head occipital-
frontal circumference by tape measure'' vital signs would also need to
record metadata for the date and time or end time of vital sign
[[Page 16819]]
measurement, the measuring- or authoring-type source of the vital sign
measurement, the patient's date of birth, and the patient's sex in
accordance with the standard we propose to adopt at Sec.
170.207(n)(1). We believe offering optional certification to these
three vital signs can provide value in settings where pediatric and
adolescent patients are provided care.
Request for Comments on Vital Signs Proposal
We intend that the LOINC[supreg] codes proposed for attribution to
the vital signs in the list above are neutral to, and therefore can
encompass, any clinically reasonable method of measurement that is
commonly used in obtaining vital signs in the course of clinical
encounters in a wide variety of contexts, including but not limited to,
primary-care office/clinic visits, emergency department visits, and
routine inpatient admissions processes. For example, this would mean
the system would attribute ``body height'' to LOINC[supreg] code 8302-2
for the measurement of how tall or long the patient is. This
measurement is collected as part of routine vital signs observation
regardless of whether this clinical observation was made by measuring a
standing or supine adult/child, or a supine infant, or by estimating
through clinically reasonable methods the height/length of an adult or
child who cannot be measured in a standing or fully supine position.
Likewise, we propose to attribute a specific LOINC[supreg] code for
body temperature regardless of whether the temperature was measured by
a liquid-filled, digital/electronic, or infrared (non-contact)
thermometer. The choice of UCUM unit code will indicate whether the
measurement was taken in English or metric units. The metadata
describing the source of the measurement would provide the context of
the device that was used to perform the measurement. We reiterate that
the intent behind this ``vital signs'' proposal is to ensure that the
data a user enters into a health IT system is semantically and
syntactically identical to the information coming out of the system and
being exchanged, allowing other users to unambiguously and consistently
interpret the information. We anticipate that stakeholders may want to
expand the list of metadata beyond the date, time, and source of vital
sign measurement. We welcome comment on additional vital sign metadata
that we should consider for inclusion and the best available standards
for representing the metadata (e.g., LOINC[supreg] or a similar
standard).
Health IT users may currently capture vital signs in more granular
LOINC[supreg] codes that specify the method of measurement. We
therefore solicit comment on the feasibility and implementation
considerations for our proposals that rely on less granular
LOINC[supreg] codes for attribution to vital sign measurements and the
inclusion of accompanying metadata. Additionally, we solicit comment on
the following issues:
Support for or against the proposal to require attribution
of vital sign values using specific LOINC[supreg] codes and associated
metadata;
whether our proposal will accomplish the stated goal of
ensuring that the vital signs data a user enters into a health IT
system is semantically and syntactically identical to the information
coming out of the system and being exchanged;
whether the LOINC[supreg] codes proposed above are the
correct ones for representing the vital sign concepts broadly,
including any method of measurement; and
standards for recording the source of the vital sign
measurement.
We also solicit comment on whether we should require a Health IT
Module to be able to record metadata specific to particular vital signs
results/findings. This could provide additional contextual information
(e.g., position for diastolic and systolic blood pressure, whether the
patient is breathing supplemental oxygen, the site of the temperature
such as oral or rectal, pregnancy status for BMI, and whether the vital
sign was measured or self-reported). Because the LOINC[supreg] code
associated with some vital sign concepts we are proposing may include
whether the vital sign was measured or self-reported (e.g., body weight
measured), we also request comment on which specific vital signs should
include metadata on whether it was measured or self-reported. If we
were to require a Health IT Module to be able to record metadata
specific to particular vital signs, we solicit comment on what
additional metadata should be required for certification and what
standards (e.g., LOINC[supreg] or a similar standard) we should
consider for representing that data.
We note, with respect to arterial oxygen saturation, that we are
proposing here the type of measurement that we understand to be
commonly performed as part of vital signs observation across a wide
variety of clinical settings. We are aware that in some clinical
circumstances oxygen saturation in arterial blood by pulse oximetry is
not a sufficiently precise measurement to support sound clinical
decisions. We therefore invite comment as to whether we should consider
defining the arterial blood oxygen saturation vital sign in a more
method-agnostic way, and whether we should also require capture and
exchange of more robust metadata to ensure technology could reliably
identify to clinicians seeking to use the value whether it was measured
by pulse oximetry or a more precise but more invasive and, in most
clinical contexts, less commonly performed arterial blood gas (ABG)
test.
We propose in a later section of this proposed rule that vital
signs be represented in same manner for the ``Common Clinical Data
Set'' definition as it applies to the certification of health IT to the
2015 Edition. Note that the optional portions of the proposed vital
signs criterion would not be required for the ``Common Clinical Data
Set'' (i.e., BMI percentile per age and sex for youth, weight for
length for infants, head occipital-frontal circumference by tape
measure, calculating BMI, and plotting and displaying growth charts.)
Please see section III.B.3 (``Common Clinical Data Set'') of this
preamble for further discussion of this associated proposal.
Problem List
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(7) (Problem list)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``problem list'' certification
criterion that is revised in one way as compared to the 2014 Edition
``problem list'' certification criterion (Sec. 170.314(a)(5)). We
propose to include the September 2014 Release of the U.S. Edition of
SNOMED CT[supreg] in the 2015 Edition ``problem list'' certification
criterion as the baseline version permitted for certification to this
criterion. The 2014 Edition ``problem list'' criterion included the
July 2012 Release of SNOMED CT[supreg] (International Release and the
U.S. Extension) as the baseline version permitted for certification. We
also refer readers to section III.A.2.d (``Minimum Standards'' Code
Sets) for further discussion of our adoption of SNOMED CT[supreg] as a
minimum standards code set and our proposal to adopt the September 2014
Release (U.S. Edition), or potentially a newer version if released
before a subsequent final rule, as the baseline for certification to
the 2015 Edition.
Medication List
[[Page 16820]]
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(8) (Medication list)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``medication list''
certification criterion that is unchanged as compared to the 2014
Edition ``medication list'' certification criterion (Sec.
170.314(a)(6)). To note, this proposed criterion does not reference any
standards or implementation specifications.
Medication Allergy List
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(9) (Medication allergy list)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``medication allergy list''
certification criterion that is unchanged as compared to the 2014
Edition ``medication allergy list'' certification criterion (Sec.
170.314(a)(7)).
We received comments in response to the Voluntary Edition proposed
rule suggesting that a ``medication allergy list'' criterion should
include also other types of allergies and intolerances, such as food
and environmental allergies (79 FR 54451-52). We are aware of a number
of vocabularies and code sets that could support food and environmental
allergies as well as medications, but believe that the industry is
working on identifying ways that multiple vocabularies and code sets
can be used together in an interoperable way to support coding of
allergies. Therefore, at this time, there is no ready solution for
using multiple vocabularies to code allergies that could be adopted for
the purposes of certification.
Clinical Decision Support
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(10) (Clinical decision support)
------------------------------------------------------------------------
Health IT is key component of advanced health models and delivery
system reform. CDS is a primary means of supporting the implementation
of best evidence and new knowledge at the point of care and in real
time (see our definition of ``CDS intervention'' discussed at 77 FR
13847). When effective decision support is presented in a useful
manner, it enhances usability and helps providers and patients avoid
medical errors. Therefore, we believe that clinical decision support is
a crucial feature of certified health IT.
We propose to adopt a 2015 Edition ``clinical decision support''
certification criterion that is revised in comparison to the 2014
Edition ``CDS'' criterion (Sec. 170.314(a)(8)). We propose to adopt
and include an updated ``Infobutton'' \32\ standard and two updated
associated IGs. We propose to require certification only to the
Infobutton standard (and an associated IG) for identifying diagnostic
or therapeutic reference information. We propose to require that a
Health IT Module presented for certification to this criterion be able
to record users' actions in response to CDS interventions. Last, we
have revised the regulation text in comparison to the 2014 Edition CDS
criterion to provide more clarity for certification to this proposed
criterion as well as guidance for certification to the 2014 Edition CDS
criterion.
---------------------------------------------------------------------------
\32\ Infobutton'' is typically the shorthand name used to refer
to the formal standard's name: HL7 Version 3 Standard: Context-Aware
Retrieval Application (Infobutton)
---------------------------------------------------------------------------
Infobutton Standard and IGs
We propose to adopt and include the updated Infobutton standard
(Release 2, June 2014) \33\ in the proposed 2015 Edition CDS criterion.
Infobutton provides a standard mechanism for health IT systems to
request context-specific clinical or health knowledge from online
resources. We propose to adopt and include the HL7 Implementation
Guide: Service-Oriented Architecture Implementations of the Context-
aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013
(``SOA Release 1 IG'') \34\ in the CDS criterion. The SOA Release 1 IG
includes additional conformance criteria, redesigns extensions, revises
possible values, and includes support for an additional format for
representing knowledge responses. We also propose to adopt and include
in the proposed 2015 Edition CDS criterion the updated Infobutton URL-
based IG (HL7 Version 3 Implementation Guide: Context-Aware Knowledge
Retrieval (Infobutton), Release 4, June 2014) (``URL-based Release 4
IG'').\35\ The IG provides a standard mechanism for health IT to submit
knowledge requests to knowledge resources over the HTTP protocol using
a standard URL format.
---------------------------------------------------------------------------
\33\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=208.
\34\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=283.
\35\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=22.
---------------------------------------------------------------------------
We propose to adopt the updated Infobutton standard with the SOA
Release 1 IG at Sec. 170.204(b)(3). We propose to adopt the updated
Infobutton standard with the URL-based Release 4 IG at Sec.
170.204(b)(4). We clarify that as proposed, a Health IT Module
presented for certification would need to demonstrate the ability to
electronically identify for a user diagnostic and therapeutic reference
information in accordance with Sec. 170.204(b)(3) or (b)(4) (i.e.,
Infobutton and the SOA Release 1 IG or Infobutton and the URL-based
Release 4 IG).
For certification to the 2014 Edition CDS criterion, we permit a
health IT to be certified if it can electronically identify for a user
diagnostic and therapeutic reference information using the Infobutton
standard or another method (Sec. 170.314(a)(8)(ii)). For the 2015
Edition CDS criterion, we propose to require that a Health IT Module
must be able to identify linked referential CDS information using the
Infobutton standard only, as we believe this is the best consensus-
based standard available to support this use case. We have taken this
approach because certification focuses on the capabilities health IT
can demonstrate (where applicable, according to specific standards) and
not on how it is subsequently used. Thus, with this focus we believe we
can refrain from continuing a regulatory requirement (i.e., requiring
``another method'' for certification) from the 2014 Edition to the 2015
Edition.
For the proposed 2015 Edition ``patient-specific education
resources'' certification criterion discussed later in this section of
the preamble, we propose, for the purposes of certification, to require
that a Health IT Module be able to request patient-specific education
resources based on a patient's preferred language. We believe this
capability would assist providers in addressing and mitigating certain
health disparities. We solicit comment on whether we should require
this functionality as part of the CDS certification criterion for
reference materials identified using the Infobutton standards,
including examples of use cases for which this functionality would be
appropriate. We note that if should require a Health IT Module to be
able to request patient-specific education resources based on a
patient's preferred language as part of the CDS criterion, the
availability of resources in a patient's preferred language depends on
the material supported by the content provider. Therefore, to clarify,
testing and certification would focus on the ability of the Health IT
Module to make the request using a preferred language and Infobutton.
CDS Intervention Response Documentation
We solicited comment in the Voluntary Edition proposed rule on
whether a Health IT Module should be able to record users' responses to
the DD/DAI checks that are performed,
[[Page 16821]]
including if and when the user viewed, accepted, declined, ignored,
overrode, or otherwise commented on the product of a DD/DAI check. We
also received comments recommending we broaden our consideration to
include functionality for recording user responses for all CDS
interventions. We believe that this functionality could be valuable for
all CDS interventions, not solely DD/DAI checks, because it could
assist with enhancing CDS intervention design and implementation,
quality improvement, and patient safety.
As such, we propose that the CDS criterion include functionality at
Sec. 170.315(a)(10)(vi) that would require a Health IT Module to be
able to record at least one action taken and by whom when a CDS
intervention is provided to a user (e.g., whether the user viewed,
accepted, declined, ignored, overrode, provided a rationale or
explanation for the action taken, took some other type of action not
listed here, or otherwise commented on the CDS intervention). We also
propose that a Health IT Module be able to generate either a human
readable display or human readable report of the responses and actions
taken and by whom when a CDS intervention is provided.
We note that we do not believe that a Health IT Module's ability to
record user responses should increase provider burden in order to just
meet this criterion. For example, we would not encourage
implementations that would unnecessarily (e.g., for a non-clinical or
safety-related reason) interrupt a provider's workflow and require the
provider to document the reason just to meet this criterion. Rather, we
encourage health IT developers to leverage current best practices for
presenting, documenting, and facilitating the safest and most
appropriate clinical options in response to CDS interventions.
Clarifying ``Automatically'' and ``Triggered'' Regulatory Text
CDS can include a broad range of decision support interventions and
are not solely limited to alerts. Our 2014 Edition ``CDS'' criterion
uses the terms ``automatically'' and ``triggered'' when referencing
interventions. The use of ``trigger'' and ``automatic'' can be
associated with CDS rules or alerts, but may not encompass all kinds of
CDS interventions. For example, CDS could be seamlessly presented in
the user interface (e.g., a dashboard display) or selected by the user
within the workflow (e.g., Infobutton or documentation flowsheets). The
use of ``automatically'' and ``trigger'' as related to CDS
interventions in the 2014 Edition ``CDS'' caused confusion as to what
types of CDS interventions were permitted. To clarify, our intent is to
encompass all types of CDS interventions without being prescriptive on
how the interventions are deployed (e.g., automatic, triggered,
selected, seamless, or queried). As such, we are not using the terms
``automatically'' and ``trigger'' as related to CDS interventions in
the regulatory text for this 2015 Edition certification criterion.
However, we do not propose to change the regulatory text language in
the 2014 Edition ``CDS'' certification criterion as current testing and
certification under the ONC Health IT Certification Program permits the
other types of interventions we have described above.
2014 Edition ``Clinical Decision Support'' Certification Criterion--
Corrections
We propose to revise the cross-reference in Sec.
170.314(a)(8)(iii)(B)(2) (CDS configuration) to more specifically
cross-reference the 2014 ToC criterion (Sec. 170.314(b)(1)(iii)(B)).
This more specific cross reference aligns with the our other proposed
revision to this criterion, which is to add a cross-reference to Sec.
170.314(b)(9)(ii)(D). We inadvertently omitted the cross-reference to
Sec. 170.314(b)(9)(ii)(D) in the 2014 Edition Release 2 final rule.
These revised cross-references would more clearly indicate that health
IT certified to the 2014 Edition CDS criterion would need to enable CDS
interventions when a patient's medications, medication allergies, and
problems are incorporated from a transition of care/care referral
summary.
Drug Formulary and Preferred Drug List Checks
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(11) (Drug-formulary and preferred drug list checks)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``drug formulary checks and
preferred drug list'' certification criterion that is revised in
comparison to the 2014 Edition ``drug formulary checks'' certification
criterion (Sec. 170.314(a)(10)). We propose a criterion that is split
based on drug formularies and preferred drug lists. For drug
formularies, we propose that a Health IT Module must (1) automatically
check whether a drug formulary exists for a given patient and
medication and (2) receive and incorporate a formulary and benefit file
according to the NCPDP Formulary and Benefit Standard v3.0 (``v3.0'').
We propose to adopt v3.0 at Sec. 170.205(n)(1), but also solicit
comment on more recent versions of the NCPDP Formulary and Benefit
Standard. For preferred drug lists, we propose that a Health IT Module
must automatically check whether a preferred drug list exists for a
given patient and medication. This situation applies where the health
IT system does not use external drug formularies, such as in a hospital
health IT system. We also propose, for both drug formularies and
preferred drug lists, that a Health IT Module be capable of indicating
the last update of a drug formulary or preferred drug list as part of
certification to this criterion. We believe that health IT should
indicate the last update of the drug formulary or preferred drug list
so the provider knows how recently the information was last updated. We
also solicit comment on the best standard for individual-level, real-
time formulary benefit checking to address the patient co-pay use case,
and whether we should offer health IT certification to the standard for
this use case.
As described in more detail in the Voluntary Edition proposed rule
(79 FR 10892), CMS finalized a proposal to recognize NCPDP Formulary
and Benefit Standard v3.0 as a backwards compatible version of NCPDP
Formulary and Benefit Standard 1.0 for the period of July 1, 2014
through February 28, 2015, and to retire version 1.0 and adopt version
3.0 as the official Part D e-Prescribing standard on March 1, 2015 (78
FR 74787-74789). In response to the Voluntary Edition proposed rule, we
received comments supporting adoption of the NCPDP Formulary and
Benefit Standard v3.0 (``v3.0'') for this edition of certification
criteria. Those commenters in support of adopting v3.0 noted the
potential to reduce file sizes, which is beneficial when checking
thousands of drug formularies on a daily basis. We agree with those
commenters that v3.0 is the best available option for standardizing the
implementation of drug-formulary checks in health IT and for its
potential to reduce file sizes. As noted above, the adoption of v3.0
would also align with CMS' adoption of version 3.0 as the official Part
D e-Prescribing standard beginning March 1, 2015.
We are aware that more recent versions of the NCPDP Formulary and
Benefit Standard. Versions 4.0 (``v4.0'') (January 2013), 4.1
(``v4.1'') (October 2013), and 42 (October 2014) (``v42'') \36\ have
been published and are available for industry use. At the time of this
[[Page 16822]]
proposed rule, we understand that the NCPDP is currently developing and
balloting Version 43 (``v43''). Version 4.0 has minor changes compared
to v3.0, including removal of values from an unused diagnosis code,
typographical corrections, and a change to the standard length of the
name field. Version 4.1 removes files to support electronic prior
authorization (ePA) transactions since these have been added to the
NCPDP SCRIPT Standard Implementation Guide v2013011 (January 2013) and
later versions, makes typographical corrections, adds a new coverage
type for ePA routing, and adds an RxNorm qualifier to some data
elements. V42 includes changes to reduce the file size. Stakeholder
feedback has indicated that v4.0, v4.1, and v42 are backwards
compatible with v3.0 for the elements that are the same as compared to
v3.0.
---------------------------------------------------------------------------
\36\ Please note a change to the naming convention to Version 42
and Version 43, as NCPDP accepted a change request to remove the
period in version numbering.
---------------------------------------------------------------------------
We received mixed comments in response to the Voluntary Edition
proposed rule on whether it is more appropriate to adopt v4.0 instead
of v3.0 (79 FR 54454). Some commenters were concerned about known
problems with v3.0 and indicated v4.0 could fix these known problems.
Conversely, other commenters stated that v4.0 was too unstable and new
for an edition of certification criteria that was anticipated to be
adopted and in use in 2014. With these comments in mind, we solicit
comment on whether we should adopt v4.0, v4.1, or v42 of the NCPDP Drug
and Formulary Benefit Standard instead of v.3.0 for the proposed 2015
Edition ``drug formulary checks and preferred drug list'' criterion and
what unintended impacts this could have on the industry given the Part
D requirements.
We believe there is value in certifying that health IT is able to
receive and incorporate a formulary and benefit file in accordance with
the NCPDP Formulary and Benefit Standard v3.0. Systems would be able to
incorporate more updated or complete formulary and benefit files to
inform providers as they make determinations about which medications to
prescribe their patients. We seek to understand the potential system
burden in incorporating formulary and benefit files and, therefore,
seek comment on this issue.
In the Voluntary Edition proposed rule, we noted that the NCPDP
Formulary and Benefit Standard v3.0 did not address individual-level,
real-time formulary benefit checking. Comments in response to the
Voluntary Edition proposed rule noted that the ASC X12 270/271 Health
Care Eligibility Benefit Inquiry and Response standard could perform
individual-level, real-time formulary benefit checking in addition to
the NCPDP Telecommunication Standard. Commenters also noted that e-
prescribing networks could provide this service to customers within
proprietary networks. We are aware of a recently established NCPDP task
group that is defining potential use cases and business requirements
for real-time benefit checking.
We continue to believe in the value of providers and patients
knowing what the patient's cost sharing responsibilities are at the
point of care for a given medication to inform discussions about a
patient's care. Therefore, for this use case, we ask commenters to
identify the best standard(s) for individual-level, real-time (at the
point of care) formulary benefit checking and describe how the standard
addresses this use case. We also solicit comment on whether we should
offer certification for this use case using the appropriate standard
for individual-level, real-time formulary benefit checking and whether
it should be part of the 2015 Edition ``drug formulary and preferred
drug list checks'' certification criterion or a standalone
certification criterion.
Smoking Status
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(12) (Smoking status)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``smoking status'' certification
criterion that is revised in comparison to the 2014 Edition ``smoking
status'' criterion (Sec. 170.314(a)(11)). We propose that a Health IT
Module must be able to record, change, and access smoking status in any
of the available codes for smoking status in, at a minimum, the
September 2014 Release of the U.S. Edition of SNOMED CT[supreg].\37\ We
have taken this more flexible approach because there is no longer a
proposed meaningful use objective and measure associated with this
requirement and, thus, no specific requirement for certain codes to be
used toward numerator calculation.
---------------------------------------------------------------------------
\37\ We refer readers to section III.A.2.d (``Minimum
Standards'' Code Sets) for further discussion of our adoption of
SNOMED CT[supreg] as a minimum standards code set and our proposal
to adopt the September 2014 Release (U.S. Edition), or potentially a
newer version if released before a subsequent final rule, as the
baseline for certification to the 2015 Edition.
---------------------------------------------------------------------------
We note, however, that the 8 smoking status SNOMED CT[supreg] codes
identified in Sec. 170.207(h) \38\ remain the same codes as identified
for the 2014 Edition. They are also the value set included in the
Common Clinical Data Set for the 2015 Edition and the only codes
permitted for representing smoking status for electronic transmission
in a summary care record for the purposes of certification. Therefore,
a Health IT Module certified to certification criteria that reference
the Common Clinical Data Set (i.e., the ToC, data portability, VDT,
Consolidated CDA creation performance, and application access to the
Common Clinical Data Set certification criteria) would need to be able
to code smoking status in only the 8 smoking status codes, which may
mean mapping other smoking status codes to the 8 codes.
---------------------------------------------------------------------------
\38\ These 8 codes are: Current every day smoker, 449868002;
current some day smoker, 428041000124106; former smoker, 8517006;
never smoker, 266919005; smoker--current status unknown, 77176002;
unknown if ever smoked, 266927001; heavy tobacco smoker,
428071000124103; and light tobacco smoker, 428061000124105.
---------------------------------------------------------------------------
We also note that we would not expect the user interface to include
a drop-down menu of all available SNOMED CT[supreg] smoking status
codes, as we believe doing so could have negative workflow effects.
Rather, we expect that health IT developers and health care providers
would work together to establish the appropriate implementation given
the care setting.
We propose to include the 2015 Edition ``smoking status''
certification criterion in the 2015 Edition Base EHR definition. Please
see section III.B.1 of this preamble for further discussion of this
associated proposal.
Image Results
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(13) (Image results)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``image results'' certification
criterion that is unchanged in comparison to the 2014 Edition ``image
results'' criterion (Sec. 170.314(a)(12)).
Family Health History
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(14) (Family health history)
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(15) (Family health history--pedigree)
------------------------------------------------------------------------
We propose to adopt two 2015 Edition ``family health history''
(FHH) certification criteria. Both proposed criteria are revised in
comparison to the 2014 Edition FHH certification criterion (Sec.
170.314(a)(13)). The proposed 2015 Edition FHH certification criterion
at Sec. 170.315(a)(14) would require
[[Page 16823]]
technology to enable a user to record, change, and access a patient's
FHH electronically according to, at a minimum, the concepts or
expressions for familial conditions included in the September 2014
Release of the U.S. Edition of SNOMED CT[supreg]. We refer readers to
section III.A.2.d (``Minimum Standards'' Code Sets) for further
discussion of our adoption of SNOMED CT[supreg] as a minimum standards
code set and our proposal to adopt the September 2014 Release (U.S.
Edition), or potentially a newer version if released before a
subsequent final rule, as the baseline for certification to the 2015
Edition.
The proposed 2015 Edition FHH--pedigree certification criterion at
Sec. 170.315(a)(15) would require technology to enable a user to
create and incorporate a patient's FHH according to HL7 Pedigree
standard and the HL7 Pedigree IG, HL7 Version 3 Implementation Guide:
Family History/Pedigree Interoperability, Release 1.\39\ We believe
that this approach gives the most flexibility to health IT developers
and providers to develop, adopt, and implement technology that supports
their clinical documentation needs, while still enabling
interoperability. For example, some providers may only need technology
that supports FHH coding in SNOMED CT[supreg]. Other providers may also
want technology that supports genomic coding, which HL7 Pedigree can
support. The adoption of two separate criteria can more effectively
support different use cases and clearly identify the capabilities to
which health IT has been certified.
---------------------------------------------------------------------------
\39\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=301.
---------------------------------------------------------------------------
As part of the 2014 Edition final rule, we incorrectly assigned the
HL7 Pedigree standard to Sec. 170.207 where we adopt ``vocabulary''
standards. Accordingly, for the 2015 Edition, we have placed the HL7
Pedigree standard and its IG in Sec. 170.205(m)(1) to more accurately
place it in the ``content'' exchange standards section of the CFR.
Patient List Creation
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(16) (Patient list creation)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``patient list creation''
certification criterion that is unchanged in comparison to the 2014
Edition ``patient list creation'' criterion (Sec. 170.314(a)(14)). We
propose to incorporate our guidance provided in FAQ 39 \40\ into the
2015 Edition ``patient list creation'' criterion. Specifically, the
text of the 2015 Edition ``patient list creation'' certification
criterion provides that a Health IT Module must demonstrate its
capability to use at least one of the more specific data categories
included in the ``demographics'' certification criterion (Sec.
170.315(a)(5)) (e.g., sex or date of birth).
---------------------------------------------------------------------------
\40\ http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039.
---------------------------------------------------------------------------
Patient-Specific Education Resources
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(17) (Patient-specific education resources)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``patient-specific education
resources'' certification criterion that is revised in comparison to
the 2014 Edition ``patient-specific education resources'' certification
criterion (Sec. 170.314(a)(15)). We propose that certification would
only focus on the use of Infobutton for this certification criterion
instead of Infobutton and any means other than Infobutton as required
by the 2014 Edition criterion. We have reviewed the regulatory burden
posed by the 2014 Edition criterion and determined that there is
diminished value in continuing to frame the 2015 Edition certification
criterion in this way. We continue to believe, however, that the
Infobutton capability is important to be available to providers to have
and use to identify patient-specific education resources.
We propose to adopt the updated Infobutton standard (Release 2 and
the associated updated IGs (SOA-based IG and URL-based IG)). These are
discussed in more detail under the ``CDS'' certification criterion
earlier in this section of the preamble. We also note that we no longer
include a requirement that health IT be capable of electronically
identifying patient-specific education resources based on ``laboratory
values/results.'' We understand from stakeholder feedback on the 2014
Edition version of this criterion and our own research that the
Infobutton standard cannot fully support this level of data
specificity. For example, Infobutton could likely provide something
useful for results that are a concept like ``E.coli,'' but not
necessarily a numerical laboratory result.
We also propose that a Health IT Module be able to request patient-
specific education resources based on a patient's preferred language as
this would assist providers in addressing and mitigating certain health
disparities. More specifically, we propose that a Health IT Module must
be able to request that patient-specific education resources be
identified (using Infobutton) in accordance with RFC 5646. We are
aware, however, that Infobutton only supports a value set of ISO 639-1
for preferred language and, therefore, testing and certification of
preferred language for this certification criterion would not go beyond
the value set of ISO 639-1. To note, we also understand that the
language of patient education resources returned through Infobutton is
dependent on what the source can support. Thus, we reiterate that
testing and certification would focus on the ability of the Health IT
Module to make the request using a preferred language and Infobutton.
Electronic Medication Administration Record
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(18) (Electronic medication administration record)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition electronic medication
administration record (eMAR) certification criterion that is unchanged
in comparison to the 2014 Edition ``eMAR'' criterion (Sec.
170.314(a)(16)).
Patient Health Information Capture
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(19) (Patient health information capture)
------------------------------------------------------------------------
We propose to adopt a new 2015 Edition ``patient health information
capture'' certification criterion that would ``replace'' the 2014
Edition ``advance directives'' certification criterion (Sec.
170.314(a)(17)) for the purposes of certification to the 2015 Edition.
The HITPC recommended, as part of their EHR Incentive Programs Stage 3
recommendations, that we adopt a certification criterion for ``advance
directives'' that would require a Health IT Module to be capable of
storing an advance directive and/or including more information about
the advance directive, such as a link to the advance directive or
instructions regarding where to find the advance directive or more
information about it.\41\ We agree with this recommendation in that
more functionality should be demonstrated for certification as it
relates to advance directives. Further, we believe that the
functionality described by the HITPC can be more broadly applicable
and, thus, have named this certification criterion to reflect
functionality that can be applied to various patient health information
documents. For example,
[[Page 16824]]
we believe such capabilities could be applicable to birth plans as well
as advance directives.
---------------------------------------------------------------------------
\41\ http://www.healthit.gov/facas/sites/faca/files/HITPC_MUWG_Stage3_Recs_2014-04-01.pdf.
---------------------------------------------------------------------------
For certification to this criterion, we propose that a Health IT
Module would need to properly identify health information documents for
users (e.g., label health information documents as advance directives
and birth plans). A Health IT Module would also need to be able to
demonstrate that it could enable a user to record (capture and store)
and access (ability to examine or review) health information documents.
We further propose that a Health IT Module would need to be able to
reference health information documents, which means providing narrative
information on where to locate a specific health information document.
A Health IT Module would also need to demonstrate that it can link to
patient health information documents. ``Linking'' would require a
Health IT Module to demonstrate it could link to an internet site
storing a health information document. While an intranet link to a
health information document might suffice for provider use, a Health IT
Module would still need to demonstrate the ability to link to an
external site via the internet for the purposes of certification.
We also propose that a Health IT Module would be required to
demonstrate that it could enable a user to record and access
information directly and electronically shared by a patient. This could
come from multiple sources, including patient information provided
directly from a mobile device. To note, we have not proposed any
specific standards for this criterion related to receiving and
accepting information directly and electronically shared by a patient.
We clarify that these capabilities may not be applicable to every
patient health information document, but a Health IT Module would need
to be able to perform all of these capabilities electronically for
certification to this criterion.
Implantable Device List
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(20) (Implantable device list)
------------------------------------------------------------------------
We propose to adopt a new 2015 Edition certification criterion
focused on the ability of a Health IT Module to record, change, and
access a list of unique device identifiers (UDIs) \42\ corresponding to
a patient's implantable devices (``implantable device list''), parse
certain data from a UDI, retrieve the ``Device Description'' attribute
associated with a UDI in the Global Unique Device Identification
Database (GUDID), and make accessible to a user both the parsed and
retrieved data. The proposed criterion represents a first step towards
enabling health IT to facilitate the widespread availability and use of
unique device identifiers to prevent device-related adverse events,
enhance clinical decision-making related to devices, improve the
ability of clinicians to respond to device recalls and device-related
safety information, and achieve other important benefits, consistent
with the fundamental aims of the HITECH Act \43\ and the HHS Health IT
Patient Safety Action and Surveillance Plan.\44\
---------------------------------------------------------------------------
\42\ A UDI is a unique numeric or alphanumeric code that
consists of two parts: (1) a device identifier (DI), a mandatory,
fixed portion of a UDI that identifies the labeler and the specific
version or model of a device, and (2) a production identifier (PI),
a conditional, variable portion of a UDI that identifies one or more
of the following when included on the label of a device: the lot or
batch number within which a device was manufactured; the serial
number of a specific device; the expiration date of a specific
device; the date a specific device was manufactured; the distinct
identification code required by 21 CFR 1271.290(c) for a human cell,
tissue, or cellular and tissue-based product (HCT/P) regulated as a
device. http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/.
\43\ Specifically, the certification criterion supports the
National Coordinator's responsibility under the HITECH Act to ensure
that the nation's health IT infrastructure supports activities that
reduce medical errors, improve health care quality, improve public
health activities, and facilitate the early identification and rapid
response to public health threats and emergencies. 42 U.S.C. 300jj-
11(b)(2) & (7).
\44\ ONC, HHS Health IT Patient Safety Action and Surveillance
Plan (July 2013), http://www.healthit.gov/policy-researchers-implementers/health-it-and-patient-safety (hereinafter ``Health IT
Safety Plan''). The first objective of the Health IT Safety Plan is
to use health IT to make care safer. See id. at 7. The Plan
specifically contemplates that ONC will update its standards and
certification criteria to improve safety-related capabilities and
add new capabilities that enhance patient safety.
---------------------------------------------------------------------------
FDA issued the Unique Device Identification System final rule on
September 24, 2013.\45\ The rule implements a statutory directive to
establish a ``unique device identification system'' for medical devices
that will enable adequate identification of devices through
distribution and use.\46\ It accomplishes this objective by requiring
device labelers (usually the device manufacturer) to include a UDI on
the label and packages of most medical devices subject to FDA
jurisdiction. In addition, for each device with a UDI, the labeler must
submit a standard set of identifying data elements to the FDA-
administered GUDID, which will be publicly accessible.\47\ Full
implementation of the UDI system for devices that are implantable,
life-saving, and life-sustaining is required by September 2015.\48\
---------------------------------------------------------------------------
\45\ 78 FR 58786.
\46\ 21 U.S.C. 360i(f).
\47\ See FDA, Global Unique Device Identification Database
(GUDID) Guidance for Industry and Food and Drug Administration Staff
(June 27, 2014), available at http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM369248.pdf.
\48\ Pursuant to 21 U.S.C. 360i(f), FDA must implement the
Unique Device Identification System Final Rule with respect to
devices that are implantable, life-saving, and life sustaining not
later than 2 years after the rule was finalized. Other
implementation and compliance dates are detailed in the final rule.
Compliance dates for UDI implementation will be phased in based on
the existing risk-based classification of medical devices: September
2014 for devices classified by FDA at the highest risk level (Class
III); September 2015 for implantable, life-supporting or life-
sustaining devices; September 2016 for moderate risk (Class II)
devices; and September 2018 for low risk (Class I) devices.
---------------------------------------------------------------------------
We first proposed to adopt a certification criterion for
implantable devices in the Voluntary Edition proposed rule (79 FR
10894). We received a large volume of comments on our proposal, many of
which supported the adoption of a UDI-related certification criterion
focused on implantable device list functionality. Some supporters of
our proposal suggested that we wait to adopt it in our next rulemaking
cycle in order to allow relevant standards and use cases to mature.
Other commenters, mostly health IT developers, suggested that the
proposed criterion would be applicable only to health IT systems
designed for surgical or specific inpatient settings in which devices
are implanted, and therefore suggested that we reduce the scope of the
criterion to those settings.\49\ For the reasons stated in the 2014
Edition Release 2 final rule,\50\ we finalized only a small subset of
the criteria we had originally proposed in the Voluntary Edition
proposed rule. These criteria focused on adding flexibility and making
improvements to the 2014 Edition. Consistent with this reduced scope,
we did not finalize an implantable device list criterion at that time,
stating instead our intention to propose such a criterion in our next
rulemaking that would provide additional detail and clarity, as well as
respond to concerns raised by commenters.
---------------------------------------------------------------------------
\49\ For a detailed summary of the comments we received on our
earlier implantable device list proposal, see the 2014 Edition,
Release 2, final rule (79 FR 54458).
\50\ 79 FR 54458.
---------------------------------------------------------------------------
We continue to believe that incorporating UDIs in health IT is
important and necessary to realize the significant promise of UDIs and
FDA's
[[Page 16825]]
Unique Device Identification System to protect patient safety and
improve health care quality and efficiency. Crucially, recording and
exchanging UDIs in patients' electronic health records would enable
this information to travel with patients as they move among providers
and throughout the health care system. With access to this information
at the point of care, clinicians can accurately identify a patient's
implantable devices and prevent adverse events resulting from
misidentification or non-identification of the device and its
associated safety characteristics (such as MRI compatibility and latex
content). Health IT could also be leveraged in conjunction with
automated identification and data capture (AIDC) or other technologies
to streamline the capture and exchange of UDIs and associated data for
patients' devices. As UDIs become ubiquitous, UDI capabilities in
health IT could facilitate better post-market surveillance of devices,
better and more accurate reporting of device-related events, and more
effective corrective and preventative action in response to device
recalls and alerts.
Fully implementing UDIs will take time and require addressing a
number of challenges. A key challenge is that UDIs may initially be
captured in any of a variety of clinical, inventory, registry, or other
IT systems. Robust adoption and use of UDIs will require bridging these
different components and changing IT and administrative processes to,
among other things, ensure that UDIs are properly captured and
associated with patients' electronic health records.
In December 2014, the Brookings Institution with collaboration from
FDA published a detailed roadmap for effective UDI implementation.\51\
Significantly, the roadmap's recommendations stated that ``while the
path to full implementation is complex, there are relatively
straightforward steps that can be done now'' to begin realizing the
benefits of UDI implementation across the health care system. The
roadmap's recommendations specifically urged ONC to support the
incorporation of UDIs into certification criteria for health IT.
---------------------------------------------------------------------------
\51\ The Brookings Institution, Unique Device Identifiers
(UDIs): A Roadmap for Effective Implementation (December 2014)
(available at http://www.brookings.http://www.brookings.edu/~/media/
research/files/papers/2014/12/
05%20medical%20device%20tracking%20system/udi%20final%2012052014).
---------------------------------------------------------------------------
We agree that a key initial step towards solving these challenges
is incorporating UDIs in certified health IT. We believe now is the
appropriate time to take that first step. Major efforts have been
underway for some time to harmonize and pilot health IT standards and
specifications in support of a variety of UDI use cases, and
substantial progress has been achieved to standardize the electronic
exchange of UDIs.\52\ In addition, FDA plans to implement the GUDID in
early 2015 and require UDIs for all implantable devices by September
2015.\53\ In light of this progress on technical standards and FDA's
timeline for UDI implementation, we believe it is feasible for health
IT developers to begin implementing the baseline functionality
necessary to use and exchange UDIs, and in particular for UDIs
associated with patient's implantable devices. Once implanted, these
devices cannot be inspected with the naked eye and are therefore more
susceptible to misidentification and resulting patient harm.
---------------------------------------------------------------------------
\52\ For example, the Brookings Institution and FDA convened a
UDI Implementation Work Group comprising device manufacturers,
payers, health IT developers, academics, clinicians, and other
stakeholders to explore opportunities and challenges associated with
capturing UDIs in claims, identifying steps for implementation and
integration of UDIs within EHRs and other health care IT
infrastructure, and utilizing UDIs as a tool for improved patient
and provider connectivity. http://www.brookings.edu/about/centers/health/projects/development-and-use-of-medical-devices/udi. The Work
Group held a series of expert workshops and in December 2014
published a detailed roadmap for effective UDI implementation. The
Brookings Institution, Unique Device Identifiers (UDIs): A Roadmap
for Effective Implementation (December 2014) (available at http://www.brookings.http://www.brookings.edu/~/media/research/files/
papers/2014/12/05%20medical%20device%20tracking%20system/
udi%20final%2012052014). Concurrently, the HL7 Technical Steering
Committee has established a UDI Task Force to ensure that UDI is
implemented in a consistent and interoperable manner across the
suite of HL7 standards. See http://hl7tsc.org/wiki/index.php?title=TSC_Minutes_and_Agendas. And through an S&I
Framework Structured Data Capture Initiative, ONC, AHRQ, FDA, and
NLM are collaborating with industry stakeholders to include UDI data
for devices in health IT adverse event reporting. See http://wiki.siframework.org/Structured+Data+Capture+Initiative. AHRQ has
already incorporated UDI and associated data attributes in its
Common Formats for adverse event reporting. See AHRQ Data
Dictionary, Common Formats Hospital Version 1.2, at 87, available at
https://www.psoppc.org/c/document_library/get_file?p_l_id=375680&folderId=431263&name=DLFE-15061.pdf.
\53\ http://www.fda.gov/MedicalDevices/ResourcesforYou/Industry/ucm427496.htm; see also 21 U.S.C. 360i(f).
---------------------------------------------------------------------------
To meet this criterion, a Health IT Module would have to enable a
user to record, change, and access a patient's implantable device list,
which would consist solely of one or more UDIs associated with a
patient's implantable devices. The Health IT Module would also have to
be able to parse the following data elements from a UDI:
Device Identifier;
Batch/lot number;
Expiration date;
Production date; and
Serial number.
In addition to parsing the UDI, a Health IT Module presented for
certification would have to be able to retrieve the optional ``device
description'' data element associated with the Device Identifier in the
GUDID, if the data element has been populated. This could be
accomplished using the GUDID's web interface, web services,
downloadable module, or any other method of retrieval permitted under
FDA's GUDID guidance.
For each UDI in a patient's implantable device list, a Health IT
Module presented for certification would have to enable a user to
access the UDI and the data elements identified above (including the
``device description,'' if it exists). Also, in addition to enabling a
user to record and access UDIs for a patient's implantable devices and
as noted above, a Health IT Module would be required to provide the
capability to change UDIs from a patient's implantable device list in
order to meet this criterion. This functionality would allow a user to
delete erroneous or duplicative entries from a patient's implantable
device list and update the list in the event that a device were removed
from the patient. We seek comment on whether such functionality is
necessary and whether there is a safer or more effective way to
maintain the accuracy of this information.
We believe that, in addition to capturing UDIs, health IT should
facilitate the exchange of UDIs in order to increase the overall
availability and reliability of information about patients' implantable
and other devices. Therefore, we propose in a later section of this
rule to include the 2015 Edition ``implantable device list''
certification criterion in the 2015 Edition Base EHR definition and
propose to include a patient's unique device identifier(s) as data
within the Common Clinical Data Set definition for certification to the
2015 Edition. Please see section III.B of this preamble for further
discussion of these associated proposals.
We have also proposed to modify Sec. 170.102 to include new
definitions for ``Device Identifier,'' ``Implantable Device,'' ``Global
Unique Device Identification Database (GUDID),'' ``Production
Identifier,'' and ``Unique Device Identifier.'' This will prevent any
ambiguity in interpretation and ensure that each term's specific
meaning reflects the same meaning given to them in the Unique Device
Identification System final rule and in 21 CFR 801.3. Capitalization
was purposefully applied
[[Page 16826]]
to each word in these defined phrases in order to signal to readers
that they have specific meanings. Please see section III.B of this
preamble for further discussion of these associated proposals.
In several respects the scope of this proposed implantable device
list criterion is narrower than the criterion we proposed in the
Voluntary Edition proposed rule. We received comments in response to
the Voluntary Edition proposed rule recommending clear standards and
use cases for an ``implantable device list'' criterion. With
consideration of these comments, unlike in the Voluntary Edition
proposed rule, we do not propose that health IT certified to the 2015
Edition ``implantable device list'' criterion be required to exchange
or display contextual information (such as a procedure note) associated
with a UDI because we believe additional standards and use case
development will be needed to support these capabilities. We request
comment on whether we have overlooked the need for or feasibility of
requiring this functionality.
We also do not propose any requirements on health IT to facilitate
the ``capture'' of UDIs at the point of care. As discussed above, UDIs
may initially be captured in any of a variety of clinical and non-
clinical contexts, many of which are beyond the current scope of health
IT certified under the ONC Health IT Certification Program. Prescribing
a requirement for capturing UDIs in certified health IT would also be
complicated by the range of data capture tools permitted under the UDI
final rule, including several different types of AIDC technology.
Moreover, as several commenters pointed out in response to our proposal
in the Voluntary Edition proposed rule, only a subset of certified
health IT users--generally surgeons or other clinicians who perform or
assist with operations involving implantable devices--would have a need
for such data capture functionality, and presumably health IT
developers who specialize in health IT for these settings can develop
appropriate solutions for these users.
Given the scope of our program and the current state of UDI
adoption, we do not believe that it would be useful to address these
``upstream'' issues at this time through rulemaking. Hence our proposal
focuses on: (1) Ensuring that certified health IT can record and
exchange UDIs for implantable devices as part of a patient's core
electronic health record using appropriate standards for
interoperability and exchange so that regardless of how UDIs are
captured, they can be readily integrated with patients' electronic
health records; (2) providing all users of certified health IT with the
ability to access basic information about patients' implantable
devices, thereby promoting greater awareness of and stimulating
additional demand for UDIs and UDI-related capabilities in health IT;
and (3) encouraging health IT developers to begin implementing GUDID
functionality. We believe that focusing on these three areas of
baseline UDI functionality will provide the greatest value to our
stakeholders and efforts to promote adoption of UDIs and realize the
significant benefits of UDIs and FDA's Unique Device Identification
System described in this proposal.
Social, Psychological, and Behavioral Data
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(21) (Social, psychological, and behavioral data)
------------------------------------------------------------------------
We propose a new 2015 Edition ``social, psychological, and
behavioral data'' certification criterion that would require a Health
IT Module to be capable of enabling a user to record, change, and
access a patient's social, psychological, and behavioral data based on
SNOMED CT[supreg] and LOINC[supreg] codes. This would include the
ability to record a patient's decision not to provide the information.
An individual's health is shaped largely by life circumstances that
fall outside the traditional health care system and include social,
psychological, and behavioral factors. These factors include, but are
not limited to, family support systems, stress, housing, nutrition,
income, and education. This proposed certification criterion to further
the collection and use of such patient data is not intended to be
comprehensive; rather, it reflects efforts to further HHS priorities to
transform health delivery, to reduce health disparities, and to achieve
the overarching goals of the National Quality Strategy. In particular,
the proposed certification criterion supports efforts to reduce
disparities and efforts to collect patient social, psychological, and
behavioral data for improved health care, such as by aligning with
recommendations from HHS and the Institute of Medicine.\54\
---------------------------------------------------------------------------
\54\ U.S. Department of Health and Human Services, Office of
Minority Health, 2011, HHS Action Plan to Reduce Racial and Ethnic
Disparities: A Nation Free of Disparities in Health and Health Care
(available at: http://www.minorityhealth.hhs.gov/npa/files/Plans/HHS/HHS_Plan_complete.pdf); U.S. Department of Health and Human
Services, Office of the Assistant Secretary for Planning and
Evaluation, 2011, Implementation Guidance on Data Collection
Standards for Race, Ethnicity, Sex, Primary Language, and Disability
Status (available at: http://aspe.hhs.gov/datacncl/standards/ACA/4302/index.pdf); and Institute of Medicine (IOM), November 2014,
Washington, DC, The National Academies Press, 2014, Capturing Social
and Behavioral Domains and Measures in Electronic Health Records:
Phase 2 (available at: http://iom.edu/Reports/2014/EHRdomains2.aspx).
---------------------------------------------------------------------------
We believe that offering certification that would require a Health
IT Module to enable a user to record, change, and access a patient's
social, psychological, and behavioral data would assist a wide array of
stakeholders (e.g., providers, consumers, payors, community-based
organizations, and state and local governments) in better understanding
how this data may adversely affect health. Ultimately, this can lead to
better health outcomes for these populations through improved patient
care, quality improvement, health equity, and clinical decision support
based on individual factors.
We also believe the self-reporting of information by individuals in
response to the questions included in these social, psychological, and
behavioral measures (i.e., the question and answer sets below) could be
utilized for the EHR Incentive Programs Stage 3 which proposes an
objective on patient engagement, including patient-generated health
data. For more information, please refer to the EHR Incentive Programs
Stage 3 proposed rule published elsewhere in this issue of the Federal
Register.
We have heard from many stakeholders recommending that we
prioritize the use of available measures and instruments for the
structured recording of social, psychological, and behavioral data, and
have followed those recommendations here. The measures (questions and
answers sets below) will have LOINC[supreg] codes (or in the case of
sexual orientation and gender identity, SNOMED CT[supreg] codes for the
answers--but no specific questions) used to identify them. Therefore,
we propose, for certification to this criterion, that social,
psychological, and behavioral data be coded in accordance with, at a
minimum, version 2.50 of LOINC[supreg] as attributed in the table
below.\55\ Please note that some question-answer sets for specific
domains do not currently have a LOINC[supreg] code in place; in these
instances it is expected that LOINC[supreg] codes will be established
in a newer version of LOINC[supreg] prior to the
[[Page 16827]]
publication of a subsequent final rule. Please further note that we
propose to include sexual orientation and gender identity within this
certification criterion as described after this table.
---------------------------------------------------------------------------
\55\ We refer readers to section III.A.2.d (``Minimum
Standards'' Code Sets) for further discussion of our adoption of
LOINC[supreg] as a minimum standards code set and our proposal to
adopt version 2.50, or potentially a newer version if released
before a subsequent final rule, as the baseline for certification to
the 2015 Edition.
----------------------------------------------------------------------------------------------------------------
LOINC[supreg]
Question(s) Answer(s) Codes for question- LOINC[supreg]
Domain [LOINC[supreg] [LOINC[supreg] answer list Answer list ID
name] answer code] combination
----------------------------------------------------------------------------------------------------------------
Financial Resource Strain How hard is it for For example: Very LOINC[supreg] code LOINC[supreg] code
(Overall financial resource you to pay for hard, Somewhat pending. pending.
strain from CARDIA). the very basics hard, Not hard,
like food, at all.\56\
housing, medical
care, and
heating? Would
you say it is . .
.
Education (Educational What is the [0] Never attended/ 63504-5........... LL1069-5.
attainment). highest level of kindergarten only.
school you have [1] 1st grade.....
completed or the [2] 2nd grade.....
highest degree [3] 3rd grade.....
you have [4] 4th grade.....
received? \57\ [5] 5th grade.....
[6] 6th grade.....
[7] 7th grade.....
[8] 8th grade.....
[9] 9th grade.....
[10] 10th grade...
[11] 11th grade...
[12] 12th grade,
no diploma.
[13] High school
graduate.
[14] GED or
equivalent.
[15] Some college,
no degree.
[16] Associate
degree:
occupational,
technical, or
vocational
program.
[17] Associate
degree; academic
program.
[18] Bachelor's
degree (e.g., BA,
AB, BS).
[19] Master's
degree (e.g., MA,
MS, MEng, MEd,
MSW, MBA).
[20] Professional
school degree
(example: MD,
DDS, DVM, JD).
[21] Doctoral
degree (example:
PhD, EdD).
[77] Refused......
[99] Don't know...
Stress (from Elo et al) \58\.... Stress means a For example: LOINC[supreg] code LOINC[supreg] code
situation in Likert scale pending. pending.
which a person ranging from 1--
feels tense, indicating not at
restless, all, 2--a little
nervous, or bit, 3--somewhat,
anxious, or is 4--quite a bit,
unable to sleep to 5--indicating
at night because very much.
his/her mind is
troubled all the
time. Do you feel
this kind of
stress these
days?
Depression (PHQ-2).............. [Patient Health N/A............... 55757-9........... N/A.
Questionnaire 2
item (PHQ-2)
[Reported]].
Little interest or [0] Not at all, 44250-9........... LL358-3.
pleasure in doing [1] Several days,
things in last 2 [2] More than
weeks half the days,
[Reported.PHQ]. [3] Nearly every
day.
Feeling down, [0] Not at all, 44255-8........... LL358-3.
depressed or [1] Several days,
hopeless in last [2] More than
2 weeks half the days,
[Reported.PHQ]. [3] Nearly every
day.
[Patient Health For example: 0-6.. 5578-7............ Answer is in UCUM
Questionnaire 2 units.\59\
item (PHQ-2)
total score
[Reported]].
Physical Activity (Exercise How many days of For example: 68515-6........... Answer is in UCUM
Vital Signs). moderate to 1,2,3,4,5,6,7, units.\60\
strenuous etc.
exercise, like a
brisk walk, did
you do in the
last 7 days?
[SAMHSA].
On those days that For example: 10, 68516-4........... Answer is in UCUM
you engage in 20, etc. units.
moderate to
strenuous
exercise, how
many minutes, on
average, do you
exercise?
[SAMHSA].
Alcohol Use (AUDIT-C)........... [Alcohol Use N/A............... 72109-2........... N/A.
Disorder
Identification
Test--Consumption
[AUDIT-C].
[[Page 16828]]
How often do you [a] Never......... 68518-0........... LL2179-1.
have a drink [b] Monthly or
containing less.
alcohol? [SAMHSA]. [c] 2-4 times a
month.
[d] 2-3 times a
week.
[e] 4 or more
times a week.
How many standard [a] 1 or 2........ 68519-8........... LL2180-9.
drinks containing [b] 3 or 4........
alcohol do you [c] 5 or 6........
have on a typical [d] 7 to 9........
day? [SAMHSA]. [e] 10 or more....
How often do you [a] Never......... 68520-6........... LL2181-7.
have six or more [b] Less than
drinks on one monthly.
occasion? [c] Monthly.......
[SAMHSA]. [d] Weekly........
[e] Daily or
almost daily.
[Total score N/A \61\.......... .................. N/A.
[AUDIT-C]].
Social Connection and Isolation Are you married or For example, these LOINC[supreg] code LOINC[supreg] code
(NHANES III). living together categories form pending. pending.
with someone in a an ordinal scale
partnership at assessing the
the time of number of types
questioning? of social
In a typical week, relationships on
how many times do which a person is
you talk on the connected and not
telephone with isolated, and has
family, friends, standard scoring.
or neighbors?. Individuals
How often do you receive one point
get together with for each of the
friends or following: Being
relatives?. married or living
How often do you together with
attend church or someone in a
religious partnership at
services?. the time of
How often do you questioning,
attend meetings averaging three
of the clubs or or more social
organizations you interactions per
belong to?. week (assessed
with questions
one and two,
above), reporting
attending church
or other
religious
services more
than four times
per year
(assessed with
question three,
above), and
reporting that
they belong to a
club or
organization
(assess with
question four,
above). A score
of 0 represents
the highest level
of social
isolation and a
score of 4
represents the
lowest level of
social isolation.
\62\
Exposure to violence: Intimate Within the last Pending........... LOINC[supreg] code LOINC[supreg] code
partner violence (HARK 4Q). year, have you pending. pending.
been humiliated
or emotionally
abused in other
ways by your
partner or ex-
partner?
Within the last ..................
year, have you
been afraid of
your partner or
ex-partner?
Within the last ..................
year, have you
been raped or
forced to have
any kind of
sexual activity
by your partner
or ex-partner?
Within the last ..................
year, have you
been kicked, hit,
slapped, or
otherwise
physically hurt
by your partner
or ex-partner?
----------------------------------------------------------------------------------------------------------------
We propose to require that a Health IT Module enable a user to
record, change, and access a patient's sexual orientation and gender
identity as part of this certification criterion. We propose that
sexual orientation be coded in accordance with, at a minimum, the
September 2014 Release of the U.S. Edition of SNOMED CT[supreg] \63\
and HL7 Version 3 attributed as follows:
---------------------------------------------------------------------------
\56\ The answer is then scored from a scale of 1 (very hard) to
3 (not at all), and unknown answers are scored as a negative number.
\57\ LOINC[supreg] Component used for the table.
\58\ Elo, A.-L., A. Lepp[auml]nen, and A. Jahkola. 2003.
Validity of a single-item measure of stress symptoms. Scandanavian
Journal of Work, Environment & Health 29(6):444-451.
\59\ Note that LOINC[supreg] provides a translation table at
https://loinc.org/downloads/usage/units that enumerates the UCUM
syntax for a subset of UCUM codes that are commonly used in health
IT that may be a useful reference for stakeholders.
\60\ Note that LOINC[supreg] provides a translation table at
https://loinc.org/downloads/usage/units that enumerates the UCUM
syntax for a subset of UCUM codes that are commonly used in health
IT that may be a useful reference for stakeholders.
\61\ The Alcohol Use Disorders Identification Test C (AUDIT-C)
is scored on a scale of 0 to 12. Each of the three AUDIT-C questions
has 5 answer choices with points ranging from 0 to 4. A screen is
considered positive for unhealthy alcohol use or hazardous drinking
if the AUDIT-C score is 4 or more points for men or 3 or more points
for women.
\62\ Pantell et al., 2013.
[[Page 16829]]
------------------------------------------------------------------------
Sexual orientation Code
------------------------------------------------------------------------
Homosexual................................ SNOMED CT[supreg] 38628009.
Heterosexual.............................. SNOMED CT[supreg] 20430005.
Bisexual.................................. SNOMED CT[supreg] 42035005.
Other..................................... HL7 V3
nullFlavor OTH.
Asked but unknown......................... HL7 V3
nullFlavor ASKU.
Unknown................................... HL7 V3
nullFlavor UNK.
------------------------------------------------------------------------
We propose that gender identity be coded in accordance with, at a
minimum, the September 2014 Release of the U.S. Edition of SNOMED
CT[supreg] \64\ and HL7 Version 3 attributed as follows:
---------------------------------------------------------------------------
\63\ We refer readers to section III.A.2.d (``Minimum
Standards'' Code Sets) for further discussion of our adoption of
SNOMED CT[supreg] as a minimum standards code set and our proposal
to adopt the September 2014 Release (U.S. Edition), or potentially a
newer version if released before a subsequent final rule, as the
baseline for certification to the 2015 Edition.
\64\ We refer readers to section III.A.2.d (``Minimum
Standards'' Code Sets) for further discussion of our adoption of
SNOMED CT[supreg] as a minimum standards code set and our proposal
to adopt the September 2014 Release (U.S. Edition), or potentially a
newer version if released before a subsequent final rule, as the
baseline for certification to the 2015 Edition.
------------------------------------------------------------------------
Gender identity Code
------------------------------------------------------------------------
Identifies as male gender................. SNOMED CT[supreg]
446151000124109.*
Identifies as female gender............... SNOMED CT[supreg]
446141000124107.*
Female-to-male transsexual................ SNOMED CT[supreg] 407377005.
Male-to-female transsexual................ SNOMED CT[supreg] 407376001.
Identifies as non-conforming gender....... SNOMED CT[supreg]
446131000124102.*
Other..................................... HL7 V3
nullFlavor OTH.
Asked but unknown......................... HL7 V3
nullFlavor ASKU
------------------------------------------------------------------------
* These new concepts will appear in the March 2015 release of the U.S.
Edition of SNOMED CT[supreg] and are now viewable at https://uscrs.nlm.nih.gov/main.xhtml.
We note that the functionality under consideration to record the
data discussed above has no bearing on whether a patient chooses to
provide this information or whether a health care provider chooses to
record the information or would be required to do so through the EHR
Incentive Programs or other programs. However, we believe the
structured recording of these types of data as described is the best
available method for reliably capturing and maintaining accurate
reflections of this information. For this proposed certification
criterion, we seek comment on whether:
The appropriate measures have been included for the listed
social, psychological, and behavioral data;
There should be standardized questions associated with the
collection of sexual orientation and gender identity data (and if so,
what vocabulary standard would be best suited for coded these
standardized questions);
We should set a minimum number of data measures for
certification (e.g., at a minimum: One, 3, or all); and
These measures should be part of one certification
criterion or separate certification criteria. We note that our proposal
for an ``Open Data Certified Health IT Products List,'' as discussed in
section IV.D.3 of this preamble, would result in more granular
identification of certified health IT. Specific to this criterion, the
CHPL would include information regarding each of the data measures
(e.g., education, depression, and sexual orientation) that were
certified as part of a Health IT Module's certification to this
criterion.
Work Information--Industry/Occupation Data
The Institute of Medicine identified patients' work information as
valuable data that could be recorded by health IT and used by both
health care providers and public health agencies.\65\ Similarly, the
2012 HHS Environmental Justice Strategy and Implementation Plan echoed
the potential benefits of having work information in EHR
technology.\66\ The combination of industry and occupation (I/O)
information provides opportunities for health care providers to improve
patient health outcomes--for health issues wholly or partially caused
by work and for health conditions whose management is affected by work.
For example, ``Usual'' (longest-held) I/O information can be key for
health care improvement and population-based health investigations, and
is already a required data element for cancer reporting.\67\ Health
care providers also can use current I/O information to assess symptoms
in the context of work activities and environments, inform patients of
risks, obtain information to assist in return-to-work determinations,
and evaluate the health and informational needs of groups of patients.
---------------------------------------------------------------------------
\65\ IOM (Institute of Medicine). 2011. ``Incorporating
Occupational Information in Electronic Health Records: A Letter
Report''. Available at: http://www.nap.edu/catalog.php?record_id=13207.
\66\ U.S. Department of Health and Human Services. February,
2012. 2012 HHS Environmental Justice Strategy and Implementation
Plan. Available at: http://www.hhs.gov/environmentaljustice/strategy.html.
\67\ CDC (2) (Centers for Disease Control and Prevention). 2012.
Implementation Guide for Ambulatory Healthcare Provider Reporting to
Central Cancer Registries, HL7 Clinical Document Architecture (CDA)
Release 1.0, August 2012. Available at: http://www.cdc.gov/phin/library/guides/Implementation_Guide_for_Ambulatory_Healthcare_Provider_Reporting_to_Central_Cancer_Registries_August_2012.pdf.
---------------------------------------------------------------------------
Since publication of the Voluntary Edition proposed rule (79 FR
10924) in which we requested comment on I/O information for the
purposes of certification, we have considered health IT developer
feedback on the need to adopt consensus standards for capturing I/O
information in health IT and continue to work with the National
Institute for Occupational Health and Safety (NIOSH) to explore avenues
to record I/O data in health IT. NIOSH also continues to work with
various industry stakeholders and health IT developers to assess the
incorporation of patient I/O fields into commercial EHRs, develop
occupationally related CDS, and to investigate practices and systems to
achieve accurate, automated coding of I/O information. Given the value
of I/O information as noted above and the progress being made by NIOSH
and others, we are making a refined request for comments as part of a
future edition of certification criteria. We invite commenters to
consider what additional support might be needed for health IT
developers, implementers, and users to effectively include a
certification criterion that would require health IT to enable a user
to record, change, and access (all electronically) the following data
elements in structured format:
Patients' employment status and primary activities (e.g.,
volunteer work);
Patients' current I/O, linked to one another and with
time-stamp, including start date;
Patients' usual I/O, linked to one another and with time-
stamp, including start year and duration in years; and
Patients' history of occupation with a time and date stamp
for when the history was collected (to note, this is focused on the
capability to record a history, not a requirement that a history must
be recorded or that a patient history be recorded for a certain
historical period of time).
We solicit public comment on the experience health IT developers
and health care providers have had in recording, coding, and using I/O
data. This would include any innovation that is making I/O data more
useful for providers.
To better understand the health care needs associated with work
data, we specifically solicit public comment from health care
providers, provider
[[Page 16830]]
organizations, and patients on the following:
The usefulness for providers to be able to access current
and usual I/O and related data in the EHR, including whether additional
data elements, such as work schedule, are useful.
The usefulness of a history of positions provided as
current I/O, with data from each position time-stamped, linked,
retained, and accessible as part of the longitudinal patient care
(medical) record.
Narrative text (vs. codes) for both current and usual I/O.
CDC_Census codes for both current and usual I/O; available
through PHIN VADS at https://phinvads.cdc.gov/vads/SearchVocab.action.
SNOMED CT[supreg] codes for occupation (current codes or
potentially developed codes).
Other standards and codes that may be in use by the health
IT industry for both current and usual I/O.
U.S. Uniformed/Military Service Data
In the Voluntary Edition proposed rule (79 FR 10924), we outlined
rationale for a potential certification criterion that would assess the
capability of health IT to enable a user to record, change, and access
U.S. military service or all uniformed service (including commissioned
officers of the U.S. Public Health Service (USPHS) and the National
Oceanographic and Atmospheric Administration (NOAA) as they too are
eligible for military health services, veterans benefits, and related
services). We reiterate the rationale here as we continue to believe it
is persuasive for adopting such a certification criterion. In recent
years, U.S. Military service members have been returning from service
in Iraq and Afghanistan and other various combat duty stations. A
portion of these service members are returning with traumatic brain
injuries, major limb injuries, and diagnoses of post-traumatic stress
disorder as reported by the Department of Defense and Department of
Veterans Affairs. We believe recording U.S. uniformed/military service
information can have many benefits. It can help in identifying
epidemiological risks for patients such as those noted above. It can
assist in ensuring that a patient receives all the health care benefits
he or she is entitled to by alerting medical professionals to the
patient's service history, which can facilitate the coordination of
benefits. This information can also increase the ability to assemble a
longitudinal record of care for a U.S. service member, such as by
requesting or merging of a patient's electronic health record stored by
the Department of Defense, Veteran's Health Administration, and/or
another health care provider.
In response to the request for comment on a ``U.S. uniformed/
military service'' certification criterion in the Voluntary Edition
proposed rule, commenters indicated that vocabulary standards for
capturing such history may not be mature enough yet. Specifically,
commenters noted that SNOMED CT [supreg] currently has relevant codes,
such as ``history relating to military service,'' and ``duration of
military service,'' but not codes to cover all potential military
service statuses, capture military service in an unambiguous way (e.g.,
capturing current employed as well as history of military service) and
military service in foreign locales. To improve coding of military and
all uniformed history, we believe a promising path forward would be to
add codes to the U.S. Extension of SNOMED-CT [supreg]. Therefore, we
request comment on the following:
Whether a potential certification criterion should be
focused solely on U.S. military service or all uniformed service
members (e.g., commissioned officers of the USPHS and NOAA);
Whether the U.S. Extension of SNOMED-CT [supreg] is the
most appropriate vocabulary code set or whether other vocabulary code
sets may be appropriate; and
The concepts/values we should use to capture U.S. military
service or all uniformed service status. We ask commenters to consider
the work of NIOSH on I/O information as it relates to capturing
military service.
Other Social, Psychological, and Behavioral Data
We seek comment on whether there are additional social,
psychological, and behavioral data that we should include for
certification as well as the best available standards for representing
such data.
Decision Support--Knowledge Artifact
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(22) (Decision support--knowledge artifact)
------------------------------------------------------------------------
We propose a new ``decision support--knowledge artifact''
certification criterion in the 2015 Edition for technology to
electronically send and receive clinical decision support knowledge
artifacts in accordance with a Health eDecisions (HeD) standard.
A previous ONC-sponsored S&I initiative, HeD, defined two use cases
(UC) with the goals of expressing CDS interventions in a standardized
format for sharing (UC 1) and requesting/receiving knowledge artifacts
from a CDS service provider (UC 2). We discuss UC 2 further in the
proposal for a 2015 Edition ``decision support--service'' certification
criterion in this section of the preamble. HeD UC 1 defined the
functional requirements needed to build a standard schema for the
contents of three ``CDS Knowledge Artifact'' \68\ types: event
condition action (ECA) rules, order sets, and documentation
templates.\69\ UC 1 was based on the scenario of a ``CDS Knowledge
Artifact supplier'' making a computable CDS Knowledge Artifact
available to a ``CDS Artifact integrator.'' For example, in accordance
with the HeD standard, health IT could automatically integrate
medication order sets based on best practice clinical guidelines in a
machine-readable format without the need for human interpretation.
---------------------------------------------------------------------------
\68\ A CDS Knowledge Artifact is the encoding of structured CDS
content as a rule to support clinical decision making in many areas
of the health care system, including quality and utilization
measures, disease outbreaks, comparative effectiveness analysis,
efficacy of drug treatments, and monitoring health trends.
\69\ HL7 Implementation Guide: Clinical Decision Support
Knowledge Artifact Implementation Guide, Release 1 (January 2013)
(``HeD standard'').
---------------------------------------------------------------------------
In the Voluntary Edition proposed rule, we proposed to adopt the
HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact
Implementation Guide, Release 1 (January 2013) (``HeD standard'').\70\
We stated that the HeD standard would greatly assist the industry in
producing and sharing machine-readable files for representations of
clinical guidance. We did not adopt the HeD standard as we agreed with
commenters that more clarity is needed regarding the HeD proposals (79
FR 54453).
---------------------------------------------------------------------------
\70\ http://wiki.siframework.org/file/detail/implementation_guide_working_final_042413_lse_uploaded-1.docx.
---------------------------------------------------------------------------
As the HeD initiative has completed, a new S&I initiative has
launched, the Clinical Quality Framework (CQF), which builds on the HeD
work and expands the scope to harmonize both CDS and electronic
clinical quality measurement (eCQM) standards. The CQF initiative has
created an updated and more modular HeD implementation guide for
sharing CDS artifacts, HL7 Version 3 Standard: Clinical Decision
Support Knowledge Artifact Specification, Release 1.2 DSTU (July
2014).\71\ The modularity allows for portions of the HeD standard
Release 1.2 to be updated without requiring updates
[[Page 16831]]
to the entire standard. As the CQF work continues, this more recent
standard will be leveraged heavily to produce a harmonized clinical
quality expression language for both CDS and eCQMs.
---------------------------------------------------------------------------
\71\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=337.
---------------------------------------------------------------------------
We continue to believe that the HeD standard would greatly assist
the industry in producing and sharing machine readable files for
representations of clinical guidance. We therefore propose to adopt the
HL7 Version 3 Standard: Clinical Decision Support Knowledge Artifact
Specification, Release 1.2 DSTU (July 2014) (``HeD standard Release
1.2'') at Sec. 170.204(d)(1) and offer testing and certification for
health IT demonstrate it can electronically send and receive a CDS
artifact formatted in the HeD standard Release 1.2.
We solicited comment in the Voluntary Edition proposed rule on what
we should test and certify to when it comes to testing and
certification for acceptance and incorporation of CDS Knowledge
Artifacts (79 FR 54453). Commenters suggested that we focus testing on
a few types of CDS Knowledge Artifacts, but not on all possible types
included in the HeD standard. We note that HHS is developing publicly
available CDS interventions in HL7 draft standard formats,\72\
including the HeD standard Release 1.2, that will be available at
www.ushik.org. We welcome comment on specific types of CDS Knowledge
Artifacts on which we should focus testing and certification to the HeD
standard Release 1.2. We also invite comments on versions of standards
we should consider as alternative options, or for future versions of
this certification criterion, given the ongoing work to harmonize CDS
and quality measurement standards as discussed under the ``CQM--record
and export'' certification criterion later in this section of the
preamble.
---------------------------------------------------------------------------
\72\ This site may also include CDS interventions formatted to
the Quality Improvement and Clinical Knowledge Model (QUICK)
standard which we discuss in the preamble for the ``Clinical quality
measures--record and export'' certification criterion.
---------------------------------------------------------------------------
Decision Support--Service
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(a)(23) (Decision support--service)
------------------------------------------------------------------------
We propose a new ``decision support--service'' certification
criterion in the 2015 Edition for technology to electronically make an
information request with patient data and receive in return electronic
clinical guidance in accordance with the standard in accordance with an
HeD standard.
A previous ONC-sponsored S&I initiative, HeD, defined two use cases
(UC) with the goals of expressing CDS interventions in a standardized
format for sharing (HeD UC 1) and requesting/receiving knowledge
artifacts from a CDS service provider (HeD UC 2). We discuss HeD UC 1
further in the proposal for a 2015 Edition ``decision support--
knowledge artifact'' certification criterion above. HeD UC 2 defines
the interface requirements needed to send patient data and receive CDS
guidance based on one scenario: a request for clinical guidance made to
a CDS guidance supplier. The HeD S&I initiative considered the
following interactions with a CDS guidance supplier: Drug dosing
calculation; immunization forecasting; disease management; quality
measure evaluation; transition of care support; test appropriateness
scores (e.g., radiology tests); prediction rule evaluation (e.g.,
APACHE score, AHRQ Pneumonia Severity Index); and severity of illness
assessment (e.g., Charlson Index). The HeD initiative created the HL7
Implementation Guide: Decision Support Service, Release 1--US Realm
DSTU (January 2014) (``Decision Support Service IG''),\73\ which
defines SOAP and REST web service interfaces for CDS guidance services.
---------------------------------------------------------------------------
\73\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=334.
---------------------------------------------------------------------------
We proposed to adopt the Decision Support Service IG in the
Voluntary Edition proposed rule because the implementation of this IG
would promote systems whereby a health care provider can send a query
about a patient to a CDS guidance supplier and receive CDS guidance
back in near real-time. Although we received general support for
adopting the Decision Support Service IG, we did not adopt it because
the 2014 Edition Release 2 final rule focused on the adoption and
revision of a small number of 2014 Edition certification criteria that
add flexibility and make improvements to the existing set of 2014
Edition certification criteria.
We are aware of a more recent release of the Decision Support
Service IG, HL7 Implementation Guide: Decision Support Service, Release
1.1 (March 2014), US Realm DSTU Specification (``Release 1.1'').\74\
Release 1.1 utilizes the latest available version of the HL7 Virtual
Medical Record specification. Given the general support we received in
the Voluntary Edition proposed rule, we propose to adopt the HL7
Implementation Guide: Decision Support Service, Release 1.1 (March
2014), US Realm DSTU Specification at Sec. 170.204(e)(1) and offer
testing and certification for health IT to demonstrate the ability to
send and receive electronic clinical guidance according to the
interface requirements defined in Release 1.1. We also invite comments
on versions of standards we could consider as alternative options, or
for future versions of this certification criterion, given the ongoing
work to harmonize CDS and quality measurement standards as discussed
under the ``CQM--record and export'' certification criterion later in
this section of the preamble.
---------------------------------------------------------------------------
\74\ http://www.hl7.org/documentcenter/public/standards/dstu/HL7_DSS_IG%20_R1_1_2014MAR.zip.
---------------------------------------------------------------------------
Transitions of Care
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(1) (Transitions of care)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition certification criterion for
``transitions of care'' (ToC) that is a continuation and extension of
the ToC certification criterion adopted as part of the 2014 Edition
Release 2 final rule at Sec. 170.314(b)(8). This proposed criterion
also reflects the corresponding structural and clarifying changes that
we adopted in the 2014 Edition Release 2 final rule that correspond to
``clinical information reconciliation and incorporation'' certification
criterion also adopted as part of the 2014 Edition final rule.
Accordingly, the 2015 Edition ToC certification criterion we
propose to adopt would include many of the same capabilities adopted at
Sec. 170.314(b)(8) with the exception of the following revisions and
additions.
Updated C-CDA Standard
As expressed in the 2014 Edition final rule, the C-CDA standard is
now the single standard permitted for certification and the
representation of summary care records. It is also referenced in other
proposed 2015 Edition certification criteria. Industry stakeholders
have continued to work to improve and refine the C-CDA standard since
the 2014 Edition final rule, including publishing additional guidance
for its consistent implementation.\75\ An updated version, HL7
Implementation Guide for CDA[supreg] Release 2: Consolidated CDA
Templates for Clinical Notes (US Realm), Draft
[[Page 16832]]
Standard for Trial Use, Release 2.0,\76\ which was balloted through
2014, includes the following changes, which we believe provide
important clarifications and enhancements:
---------------------------------------------------------------------------
\75\ http://wiki.siframework.org/Companion+Guide+to+Consolidated+CDA+for+MU2.
\76\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379. Access to the IG is freely
available for review during the public comment period by
establishing an HL7 user account.
---------------------------------------------------------------------------
Addition of new structural elements: new document sections
and data entry templates:
[cir] New Document Templates for: Care Plan; Referral Note;
Transfer Summary.
[cir] New Sections for: Goals; Health Concerns; Health Status
Evaluation/Outcomes; Mental Status; Nutrition; Physical Findings of
Skin.
[cir] New organizers and many new entries (e.g. Wound Observation).
Some sections/entries were deprecated (i.e., should no
longer be used).
Updates to (versioning of) template/section/entry object
identifiers (OIDs).
[cir] This includes a new chapter describing HL7's approach to
template versioning.
Tighter data constraints/requirements.
[cir] For example, some data elements with a ``MAY'' requirement
now have a ``SHOULD'' requirement. Likewise, some with a ``SHOULD''
requirement now have a ``MUST'' requirement.
Updated Vocabulary/Value Set constraints.
[cir] For example: two SNOMED CT [supreg] codes were added to the
Current Smoking Status value set and the Tobacco Use value set to
support the 2014 Edition vocabulary requirements for patient smoking
status.
[cir] NLM's Value Set Authority Center (VSAC) was named as
reference for Value Sets used in C-CDA.
In the Voluntary Edition proposed rule, we proposed to adopt the C-
CDA Release 2.0 standard and reference its use in the other
certification criteria in which this standard would have also been
applicable. At the time of that proposal, the C-CDA Release 2.0 had not
yet completed its balloting cycle within HL7 and stakeholder comments
on the Voluntary Edition proposed rule expressed concern related to the
C-CDA Release 2.0 standard's stability. Given that the C-CDA Release
2.0 has completed balloting and is now published as the next C-CDA
version, we believe that the continued attention it received through
HL7 balloting has resulted in a standard that is the best available for
adoption in this proposed rule and for future implementation in the
coming years. Thus, we propose to adopt C-CDA Release 2.0 at Sec.
170.205(a)(4) as part of this certification criterion. We note that
compliance with the C-CDA Release 2 cannot include the use of the
``unstructured document'' document-level template for certification to
this criterion.
To address a technical implementation challenge sometimes referred
to as ``bilateral asynchronous cutover,'' (which is meant to convey the
complexity of continued interoperability among exchange partners as
each upgrades their health IT at different times and with different
standards capabilities), we propose that the 2015 Edition ToC
certification criterion reference both the C-CDA Release 1.1 and
Release 2.0 standards. In other words, a Health IT Module presented for
certification to this criterion would need to demonstrate its
conformance and capability to create and parse both versions (Release
1.1 and 2.0) of the C-CDA standards. Under this proposal, the sending
Health IT Module would send two documents (one conforming to C-CDA R1.1
and other conforming to C-CDA R2.0) and the receiving Health IT Module
would receive both versions of the documents and choose the appropriate
version for downstream processing.
While we recognize that this proposal is not ideal, we have
proposed this more conservative approach as a way to mitigate the
potential that there would be interoperability challenges for ToC as
different health care providers adopt Health IT Modules certified to
the 2015 Edition criterion at different times that include C-CDA
Release 2.0 capabilities. However, we request public comment,
especially from health IT developers with experience implementing the
C-CDA, on an alternative approach related to the creation of C-CDA-
formatted documents. The alternative approach would be focused on C-CDA
creation and receipt capabilities related to whether the health IT
system could produce one, ``dually compliant,'' C-CDA that addresses
both C-CDA versions at once. We understand that this approach is
possible, may be preferred from an implementation perspective, and
could help prevent potential data duplication errors that could result
if a Health IT Module is required to be able to produce two separate C-
CDA files (one in each version) as part of certification.
Our proposal to adopt C-CDA Release 2.0 is applicable to all of the
other certification criteria in which the C-CDA is referenced.
Similarly, unless C-CDA Release 2.0 is explicitly indicated as the sole
standard in a certification criterion, we propose to reference both C-
CDA versions in each of these criteria for the reasons just discussed.
Valid/Invalid C-CDA System Performance
As we considered stakeholder feedback and reviewed the additional
public dialogue surrounding the variability of CEHRT in recognizing
valid/invalid documents formatted according to the C-CDA 1.1 standard,
including structured content by different health IT developers,\77\ we
recognized that an expanded ToC certification criterion with a specific
capability focused principally on health IT system behavior and
performance related to recognizing valid/invalid C-CDAs would be
beneficial. Thus, we propose to include within the 2015 Edition ToC
certification criterion a specific focus on this technical system
behavior. We believe this type of error checking and resilience is an
important and necessary technical prerequisite in order to ensure that
as data in the system is parsed from a C-CDA for incorporation as part
of the ``clinical information reconciliation and incorporation''
certification criterion the user can be assured that the system has
appropriately interpreted the C-CDA it received. Further, we believe
this level of rigorous testing will better enable Health IT Modules to
properly recognize C-CDA-based documents and prepare the necessary
information for reconciliation and other workflow needs.
---------------------------------------------------------------------------
\77\ D'Amore JD, et al. J Am Med Inform Assoc 2014;21:1060-1068.
---------------------------------------------------------------------------
We propose that this specific aspect of the certification criterion
would focus on and require the following technical outcomes be met. The
Health IT Module would need to demonstrate the ability to detect valid
and invalid C-CDA documents, including document, section, and entry
level templates for data elements specified in 2014 and 2015 edition.
Specifically, this would include:
The ability of the Health IT Module to detect invalid C-
CDA documents. Thus, any data in the submitted C-CDA document that does
not conform to either the C-CDA 1.1 or 2.0 standard (in addition to
data coding requirements specified by this regulation) would be
considered invalid;
The ability to identify valid C-CDA document templates
(e.g., CCD, Discharge Summary, Progress Note) and process the required
data elements, section and entries, specific to the document templates
and this regulation.
The ability to detect invalid vocabularies and codes not
specified in
[[Page 16833]]
either the C-CDA 1.1 or 2.0 standard or required by this regulation
(e.g., using a SNOMED CT [supreg] code where a LOINC [supreg] code is
required or using a code which does not exist in the specified value
set).
The ability to correctly interpret empty sections and
nullFlavor combinations per the C-CDA 1.1 or 2.0 standard. For example,
we anticipate testing could assess a Health IT Module's ability to
continue to process a C-CDA when a nullFlavor is used at the section
template level.
We expect these capabilities would be tested by providing several
C-CDA documents with valid and invalid data. We do not expect Health IT
Modules presented for certification to have a common C-CDA handling
process, however, we do expect that they would have a baseline
capability to identify valid and invalid C-CDA documents and prepare
the necessary data for clinical information reconciliation and
incorporation. Further, we expect that Health IT Modules will have some
mechanism to track errors encountered when assessing received C-CDA's
and we have proposed that health IT be able to track the errors
encountered and allow for a user to be notified of errors or review the
errors produced. The Health IT Module would not need to support both
and how this technical outcome is accomplished is entirely up to the
health IT developer.
We direct readers to the proposed ``Consolidated CDA creation
performance'' certification criterion (Sec. 170.315(g)(6)) under which
we seek comment on a potential requirement for this certification
criterion or the ``Consolidated CDA creation performance''
certification criterion that would evaluate the completeness of the
data included in a C-CDA in order to ensure that the data recorded by
health IT is equivalent to the data included in a created C-CDA.
XDM Package Processing
As indicated in the earlier paragraphs, a Health IT Module
presented for certification to this certification criterion will need
to support one of the edge protocols referenced in the Edge IG version
1.1 (i.e., the ``IHE XDR profile for Limited Metadata Document
Sources'' edge protocol or an SMTP-focused edge protocol (SMTP alone or
SMTP in combination with either IMAP4 or POP3)). However industry
feedback has indicated that the use of XDM packages has grown within
the stakeholder community using Direct, which most often happens when
Edge System A using XDR sends content and metadata to its HISP-A, who
in turn packages that content and metadata into an XDM ZIP and sends it
within a Direct message to HISP-B, which then ultimately sends the
message containing the XDM package to Edge System B using an SMTP-based
edge.
Therefore, if Edge System B does not support XDM package
processing, interoperability could be impacted when HISP-B forwards XDM
packages to Edge System B via the SMTP protocol. To mitigate this
potential incompatibility, we propose to include a specific capability
in this certification criterion that would require a Health IT Module
presented for certification that is also being certified to the SMTP-
based edge to demonstrate its ability to accept and process an XDM
package it receives, which would include extracting relevant metadata
and document(s). That is, this additional requirement only applies to a
Health IT Module presented for certification with an SMTP-based edge
implementation and not an XDR edge implementation). Additionally,
because we expect XDM packaging to be created in accordance with the
specifications included in IHE IT Infrastructure Technical Framework
Volume 2b (ITI TF-2b),\78\ we propose to adopt this as the standard (at
Sec. 170.205(p)(1)) for assessing whether the XDM package was
successfully processed.
---------------------------------------------------------------------------
\78\ http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev7-0_Vol2b_FT_2010-08-10.pdf.
---------------------------------------------------------------------------
Common Clinical Data Set
We propose to include an updated Common Clinical Data Set for the
2015 Edition that includes references to new and updated vocabulary
standards code sets. Please also see the Common Clinical Data Set
definition proposal in section III.B.3 of this preamble.
Encounter Diagnoses
For encounter diagnoses, we are carrying over the requirement from
the 2014 Edition ``ToC'' certification criterion that a Health IT
Module must enable a user to create a transition of care/referral
summary that also includes encounter diagnoses using either SNOMED CT
[supreg] (September 2014 Release of the U.S. Edition as a baseline for
the 2015 Edition) or ICD-10 codes.
``Create'' and Patient Matching Data Quality
In 2011, both the HITPC and HITSC made recommendations to ONC on
patient matching. The HITPC made recommendations in the following five
categories: Standardized formats for demographic data fields;
internally evaluating matching accuracy; accountability; developing,
promoting and disseminating best practices; and supporting the role of
the individual/patient.\79\ The HITSC made the following four
recommendations: Detailing patient attributes that could be used for
matching (in order to understand the standards that are needed); data
quality; formats for these data elements; and what data are returned
from a match request.\80\ The standards recommended by the HITSC are as
follows:
---------------------------------------------------------------------------
\79\ http://www.healthit.gov/sites/default/files/hitpc-transmittal-letter-priv-sectigerteam-020211.pdf.
\80\ http://www.healthit.gov/FACAS/sites/default/files/standards-certification/8_17_2011Transmittal_HITSC_Patient_Matching.pdf.
---------------------------------------------------------------------------
Basic Attributes: Given Name; Last Name; Date of Birth;
Administrative Gender.\81\
---------------------------------------------------------------------------
\81\ Despite its inclusion of the word ``gender,''
``Administrative Gender'' is generally used in standards to
represent a patient's ``sex,'' such as male or female. See: http://ushik.ahrq.gov/ViewItemDetails?system=hitsp&itemKey=83680000.
---------------------------------------------------------------------------
Other Attributes: Insurance Policy Number; Medical Record
Number; Social Security Number (or last 4 digits); Street Address;
Telephone Number; Zip Code.
Potential Attributes: Email Address; Voluntary
Identifiers; Facial Images; Other Biometrics.
In July 2013, ONC launched an initiative to reinvigorate public
discussion around patient matching, to perform a more detailed analysis
of patient matching practices, and to identify the standards, services,
and policies that would be needed to implement the HITPC and HITSC's
recommendations. The initiative's first phase focused on a common set
of patient attributes that could be leveraged from current data and
standards referenced in our certification criteria. Given the initial
findings, we proposed to include a limited set of standardized data as
a part of the ``Create'' portion of the ToC criterion in the Voluntary
Edition proposed rule to improve the quality of the data included in
outbound summary care records. Overall, the vast majority of commenters
supported the proposed policy that standardized patient attributes
should be required for use in as part of the transitions of care
certification criterion. Commenters overwhelmingly supported the
inclusion of the proposed constrained specifications for last name/
family name, maiden name, suffix, first/given name, middle/second name,
maiden name, date of birth, current address and historical address,
phone number, and sex in support of patient matching. However, given
our approach in the 2014 Edition Release 2 final rule
[[Page 16834]]
to only adopt a small subset of the proposed certification criteria to
provide flexibility, clarity, and enhance health information exchange,
we decided not adopted this proposal.
We again propose to include a limited set of standardized data as a
part of the ``Create'' portion of the ToC criterion in the 2015 Edition
to improve the quality of the data included in outbound summary care
records. To be clear, this proposal does not require a Health IT Module
to capture the data upon data entry, but rather at the point when the
data is exchanged (an approach commonly used for matching in HL7
transactions, IHE specifications,\82\ C-CDA specification, and the
eHealth Exchange). The proposed standardized data include: first name,
last name, middle name (including middle initial), suffix, date of
birth, place of birth, maiden name, phone number, and sex. In the
bulleted list below, we identify more constrained specifications for
some of the standardized data we propose. Based on our own research, we
do not believe that the proposed constraints to these data conflict
with the C-CDA. That being said, some proposed constraints may further
restrict the variability as permitted by existing specifications and
others may create new restrictions that do not currently exist within
the C-CDA. We propose that:
---------------------------------------------------------------------------
\82\ http://www.ihe.net/Technical_Frameworks/.
---------------------------------------------------------------------------
For ``last name/family name'' the CAQH Phase II Core 258:
Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule
version 2.1.0 \83\ (which addresses whether suffix is included in the
last name field) be followed.
---------------------------------------------------------------------------
\83\ http://www.caqh.org/pdf/CLEAN5010/258-v5010.pdf.
---------------------------------------------------------------------------
For ``suffix,'' that the suffix should follow the CAQH
Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient
Last Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, Ph.D.,
ESQ) \84\ and that if no suffix exists, the field should be marked as
null.
---------------------------------------------------------------------------
\84\ http://www.caqh.org/pdf/CLEAN5010/258-v5010.pdf.
---------------------------------------------------------------------------
For ``date of birth,'' that the year, month and date of
birth should be required fields while hour, minute and second should be
optional fields. If hour, minute and second are provided then either
time zone offset should be included unless place of birth (city,
region, country) is provided; in the latter local time is assumed. If
date of birth is unknown, the field should be marked as null.
For ``phone numbers,'' the ITU format specified in ITU-T
E.123 \85\ and ITU-T E.164 \86\ be followed and that the capture of
home, business, and cell phone numbers be allowed.\87\ Further, that if
multiple phone numbers are present in the patient's record, all should
be included in the C-CDA and transmitted.
---------------------------------------------------------------------------
\85\ http://www.itu.int/rec/T-REC-E.123-200102-I/e.
\86\ http://www.itu.int/rec/T-REC-E.164-201011-I/en.
\87\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186.
---------------------------------------------------------------------------
For ``sex'' we propose to require developers to follow the
HL7 Version 3 Value Set for Administrative Gender and a nullFlavor
value attributed as follows: M (Male), F (Female), and UNK (Unknown).
While the Patient Matching Initiative's recommendations included
standardizing current and historical address, we have not included a
specific standardized constraint for that data at this time due to a
lack of consensus around the proper standard. In response to the
Voluntary Edition proposed rule, commenters also suggested that we
delay support for international standards for address until future
editions of certification criteria. To reiterate, the data we propose
for patient matching would establish a foundation based on leveraging
current data and standards in certification criteria. We welcome
comments on this approach and encourage health IT developers to
consider and support the use other patient data that would improve
patient matching for clinical care and many types of clinical research.
Direct Best Practices
In the past couple of years we have heard feedback from
stakeholders regarding health IT developers limiting the transmission
or receipt of different file types via Direct. We wish to remind all
stakeholders of the following best practices for the sharing of
information and enabling the broadest participation in information
exchange with Direct: http://wiki.directproject.org/Best+Practices+for+Content+and+Workflow.
Certification Criterion for C-CDA and Common Clinical Data Set
Certification
We note that no proposed 2015 Edition health IT certification
criteria includes just the C-CDA Release 2.0 and/or the Common Clinical
Data Set, particularly with the 2015 Edition not including a proposed
``clinical summary'' certification criterion as discussed later on in
this preamble. Health IT certified to simply the C-CDA Release 2.0 with
or without certification to the Common Clinical Data Set may be
beneficial for other purposes, including participation in HHS payment
programs. We request comment on whether we should adopt a separate 2015
Edition health IT certification criterion for the voluntary testing and
certification of health IT to the capability to create a summary record
formatted to the C-CDA Release 2.0 with or without the ability to meet
the requirements of the Common Clinical Data Set definition.
C-CDA Data Provenance Request for Comment
As the exchange of health data increases, so does the demand to
track the provenance of this data over time and with each exchange
instance. Confidence in the authenticity, trustworthiness, and
reliability of the data being shared is fundamental to robust privacy,
safety, and security enhanced health information exchange. The term
``provenance'' in the context of health IT refers to evidence and
attributes describing the origin of electronic health information as it
is captured in a health system and subsequently persisted in a way that
supports its lifespan. As described in the President's Council of
Advisors on Science and Technology (PCAST) Report ``Realizing the Full
Potential of Health Information Technology to Improve Healthcare for
Americans'' \88\, provenance includes information about the data's
source and the processing that the data has undergone. The report
refers to ``tagged data elements'' as units of data accompanied by a
``metadata tag'' that describes the attributes, provenance, and
required security protections of the data.
---------------------------------------------------------------------------
\88\ PCAST Report to the President: Realizing the Full Potential
of Health Information Technology to Improve Healthcare for
Americans: The Path Forward, http://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf.
---------------------------------------------------------------------------
In April 2014, ONC launched the Data Provenance Initiative within
the Standards and Interoperability (S&I) Framework to identify the
standards necessary to capture and exchange provenance data, including
provenance at time of creation, modification, and time of exchange.\89\
The stakeholder community represented a wide variety of organizations
including health IT developers; federal, state, and local agencies;
healthcare professionals; research organizations; payers; labs; and
individuals within academia. In the fall of 2014, the HL7 IG for CDA
Release 2: Data Provenance, Release 1 (US Realm) (DSTU) \90\ was
published. This IG
[[Page 16835]]
clarifies existing content from various standards within HL7 \91\ and
describes how provenance information for a CDA document in a health IT
system should be applied, and what vocabulary should be used for the
metadata. This includes provenance metadata in the CDA at the header,
section and entry levels. We seek comment on the maturity and
appropriateness of this IG for the tagging of health information with
provenance metadata in connection with the C-CDA. Additionally, we seek
comment on the usefulness of this IG in connection with certification
criteria, such as ToC and VDT certification criteria.
---------------------------------------------------------------------------
\89\ http://wiki.siframework.org/Data+Provenance+Initiative.
\90\ http://wiki.hl7.org/index.php?title=HL7_Data_Provenance_Project_Space and http://gforge.hl7.org/gf/project/cbcc/frs/?action=FrsReleaseBrowse&frs_package_id=240.
\91\ Standards including HL7 Clinical Documentation Architecture
Release 2 (CDA R2), HL7 Implementation Guide: Data Segmentation for
Privacy (DS4P), Release 1, and HL7 Version 2 Vocabulary &
Terminology Standards (all are normative standards).
---------------------------------------------------------------------------
Clinical Information Reconciliation and Incorporation
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(2) (Clinical information reconciliation and
incorporation)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``clinical information
reconciliation and incorporation'' certification criterion that is a
revised (but largely similar to the 2014 Edition Release 2) version of
the ``clinical information reconciliation and incorporation'' criterion
adopted at Sec. 170.314(b)(9).
Incorporation System Performance
As we considered public comments made after the 2014 Edition final
rule and reviewed the additional public dialogue surrounding the
variability of certified health IT in incorporating C-CDAs including
structured content by different health IT developers \92\, we
recognized the need to expand the existing ``clinical information
reconciliation and incorporation'' certification criterion to focus on
health IT system behavior and performance related to incorporating C-
CDAs including structured content. We believe that testing a Health IT
Module's capability to reconcile and incorporate, at a minimum:
problems, medications, and medication allergies from multiple C-CDAs
will improve the overall clinical effectiveness.
---------------------------------------------------------------------------
\92\ D'Amore JD, et al. J Am Med Inform Assoc 2014; 21:1060-
1068.
---------------------------------------------------------------------------
We expect that testing for this specific system performance would
include the ability to incorporate valid C-CDAs with variations of data
elements to be reconciled (e.g., documents with no medications,
documents having variations of medication timing data). In addition we
believe we can further strengthen this certification criterion by
proposing to require that a C-CDA be created based on the
reconciliation and incorporation process in order to validate the
incorporation results. We anticipate that the generated C-CDA would be
verified using test tools for conformance and can be checked against
the information that was provided to incorporate.
Accordingly, we propose that the following technical system
behavior and performance also be addressed as part of the clinical
information reconciliation and incorporation certification criterion:
The Health IT Module must demonstrate the ability to reconcile problem,
medication, and medication allergy data from valid C-CDAs (both Release
1.1. and 2.0) with variations of data elements to be reconciled and
then generate a conformant C-CDA document based on the reconciled
information. For example, a test could include assessing a Health IT
Module's capability to reconcile and incorporate medication information
with different timing information.
Electronic Prescribing (e-Prescribing)
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(3) (Electronic prescribing)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition certification criterion for e-
prescribing that is revised in comparison to the 2014 Edition ``e-
prescribing'' criterion (Sec. 170.314(b)(3)). First, for the purposes
of certification, we propose to require a Health IT Module to be able
to receive and respond to additional NCPDP SCRIPT Standard
Implementation Guide Version 10.6 (v10.6) transactions or segments,
namely Change Prescription, Refill Prescription, Cancel Prescription,
Fill Status, and Medication History. Second, for the purposes of
certification, we propose to require that a Health IT Module
demonstrate that directions for medication use transmitted as e-
prescriptions are codified in a structured format. Third, for the
purposes of certification, we propose to require a Health IT Module be
able to limit a user to e-prescribing all medications in the metric
unit standard only, follow NCPDP-recommended conventions for use of
leading zeroes before a decimal, and avoid use of trailing zeroes after
a decimal when e-prescribed.
e-Prescribing Transactions or Segments
For 2014 Edition testing and certification to this criterion, a
Health IT Module presented for certification must demonstrate that it
can create a new prescription according to the NCPDP SCRIPT v10.6 New
Prescription transaction (NEWRX). Stakeholders have recommended we
consider expanding testing to a greater number of NCPDP SCRIPT v10.6
transactions and segments in order to better facilitate prescriber and
pharmacist communications to provide better care for patients.
Stakeholders have indicated that there is variable uptake and
inconsistent implementation of the transactions in the NCPDP SCRIPT
Standard v10.6 despite their added value for patient safety and
improved communication between prescribers and pharmacists. In
consideration of stakeholder input, we propose to include additional
NCPDP SCRIPT v10.6 transactions in addition to the New Prescription
transaction for health IT testing and certification. We propose that
testing and certification would require a Health IT Module to
demonstrate the ability to send and receive end-to-end prescriber-to-
receiver/sender-to-prescriber transactions (bidirectional
transactions). The transactions and reasons for inclusion for testing
and certification are outlined in Table 3 below.
[[Page 16836]]
Table 3--Proposed Additional \93\ NCPDP SCRIPT v10.6 Transactions for Testing and Certification to e-Prescribing
Certification Criterion
----------------------------------------------------------------------------------------------------------------
NCPDP SCRIPT v10.6 transaction or Problem addressed/value in
segment Use case(s) testing for certification
----------------------------------------------------------------------------------------------------------------
Change Prescription (RXCHG, CHGRES).. Allows a pharmacist to request a Facilitates more efficient,
change of a new prescription or a standardized electronic
``fillable'' prescription. communication between
Allows a prescriber to respond to prescribers and pharmacists
pharmacy requests to change a for changing prescriptions.
prescription.
Cancel Prescription (CANRX, CANRES).. Notifies the pharmacist that a Facilitates more efficient,
previously sent prescription should be standardized electronic
canceled and not filled. communication between
prescribers and pharmacists
for cancelling
prescriptions.
Sends the prescriber
the results of a
prescription cancellation
request.
Refill Prescription (REFREQ, REFRES). Allows the pharmacist to request Facilitates more efficient,
approval for additional refills of a standardized electronic
prescription beyond those originally communication between
prescribed. prescribers and pharmacists
for refilling prescriptions.
Allows the prescriber to grant
the pharmacist permission to provide a
patient additional refills or decline to
do so.
Fill Status (RXFILL)................. Allows the pharmacist to notify the Allows the prescriber to know
prescriber about the status of a whether a patient has picked
prescription in three cases: 1) to notify up a prescription, and if
of a dispensed prescription, 2) to notify so, whether in full or in
of a partially dispensed prescription, 3) part. This information can
to notify of a prescription not inform assessments of
dispensed. medication adherence.
Medication History (RXHREQ, RXHRES).. Allows a requesting entity to Allows a requesting entity to
generate a patient-specific medication receive the medication
history request. history of a patient. A
The responding entity can respond prescriber may use this
with a patient's medication history, information to perform
including source, fill number, follow-up medication utilization
contact, date range, as information is review, medication
available. reconciliation, or other
medication management to
promote patient safety.
----------------------------------------------------------------------------------------------------------------
We solicit comment on including the proposed transactions and
segments for testing and certification to this certification criterion
as outlined in Table 3, and on the problems addressed/value in testing
for certification. We also solicit comment on the following issues:
---------------------------------------------------------------------------
\93\ We are proposing to keep the ``New Prescription''
transaction for testing and certification.
---------------------------------------------------------------------------
Other NCPDP SCRIPT v10.6 transactions that should be
considered for testing and certification, and for what use cases/value;
What factors we should consider for end-to-end prescriber-
to-receiver testing.
We also propose to adopt and include the February 2, 2015 monthly
version of RxNorm in this criterion as the baseline version minimum
standards code set for coding medications (see section III.A.2.d
(``Minimum Standards'' Code Sets) of this preamble).
Structured and Codified ``Sig''
Medications can be e-prescribed using a free text format, and
typically the instructions include the medication name, dose, route of
administration, frequency of administration, and other special
instructions. This set of prescribing instructions is referred to as
the ``Sig.'' In a free text format, non-standard or conflicting
language may be used that is not understood by the pharmacist filling
the prescription. Where systems do facilitate creation of the Sig, some
systems may auto-concatenate the field length and thus the tail end of
the Sig is lost. This has implications for communication between
prescribers and pharmacists as well as for patient safety. Prescribers
and pharmacists may have to engage in back-and-forth communication to
clarify what is intended in the Sig instructions. Therefore, there is
an opportunity to streamline prescriber-pharmacist communication, allow
more time for direct activities of patient care, and reduce confusion
during the pharmacy verification and dispensing processes.
We are aware that the NCPDP SCRIPT v10.6 standard includes
structured Sig segments that are used to codify the prescribing
directions in a structured format.\94\ Providing Sig instructions in a
structured format promotes accurate, consistent, and clear
communication of the prescribing information as intended by the
prescriber.
---------------------------------------------------------------------------
\94\ NCPDP's Structured and Codified Sig Format Implementation
Guide v1.2 is adopted within SCRIPT v10.6.
---------------------------------------------------------------------------
In one study of the structured and codified Sig within NCPDP SCRIPT
v10.5, the Sig format fully represented 95% of ambulatory prescriptions
tested.\95\ While we believe that the results of this study give an
indication of the scope of the structured and codified Sig within NCPDP
SCRIPT v10.5, we note that the Sig standard was tested in the lab
environment and not with live end-users. Stakeholders have also
indicated the limitations of the structured and codified Sig within
NCPDP SCRIPT v10.6 to represent all Sig instructions, particularly
complex Sigs requiring multi-step directions. For example, stakeholders
have noted that the Sig segment within the NCPDP SCRIPT v10.6 standard
limits the field length to 140 characters whereas later versions of the
NCPDP SCRIPT standard (from v201311 onward) have expanded the character
length to 1000. Despite these potential limitations, we see
standardizing and codifying the majority of routine prescriptions as a
means to promote patient safety as well as reduce disruptions to
prescriber workflow through a reduction in pharmacy call-backs.
---------------------------------------------------------------------------
\95\ Liu H, Burkhart Q and Bell DS. Evaluation of the NCPDP
Structured and Codified Sig Format for e-prescriptions. J Am Med
Inform Assoc. 2011 Sep-Oct;18(5):645-51.
---------------------------------------------------------------------------
We note the flexibility to create complex unstructured Sigs remains
through use of existing e-prescribing workflow and appropriate use of
the free text field. There is, however, low uptake of structured Sig
according to the NCPDP SCRIPT v10.6 standard, which includes a
combination of mandatory and conditional structured Sig segments.
We believe that medication Sig instructions should be codified in a
[[Page 16837]]
structured format for the benefits outlined above. Therefore, we
propose to require that a Health IT Module enable a user to enter,
receive, and transmit codified Sig instructions in a structured format
in accordance with NCPDP Structured and Codified Sig Format
Implementation Guide v1.2 which is embedded within NCPDP SCRIPT v10.6
for certification to the e-prescribing criterion in the 2015
Edition.\96\ We propose that this requirement apply to the New
Prescription, Change Prescription, Refill Prescription, Cancel
Prescription, Fill Status, and Medication History prescription
transactions or segments as we understand that the NCPDP Structured and
Codified Sig Format can be used for all NCPDP SCRIPT v10.6 prescription
transactions that include the medication field. We also propose to
require that a Health IT Module include all structured Sig segment
components enumerated in NCPDP SCRIPT v10.6 (i.e., Repeating Sig, Code
System, Sig Free Text String, Dose, Dose Calculation, Vehicle, Route of
Administration, Site of Administration, Sig Timing, Duration, Maximum
Dose Restriction, Indication and Stop composites).
---------------------------------------------------------------------------
\96\ NCPDP's Structured and Codified Sig Format Implementation
Guide v1.2 is within the NCPDP SCRIPT v10.6 standard.
---------------------------------------------------------------------------
We are aware that NCPDP has recently published recommendations for
implementation of the structured and Codified Sig format for a subset
of component composites that represent the most common Sig segments in
the NCPDP SCRIPT Implementation Recommendations Version 1.29.\97\ We
therefore welcome comment on this proposal, including whether we should
require testing and certification to a subset of the structured and
codified Sig format component composites that represent the most common
Sig instructions rather than the full NCPDP Structured and Codified Sig
Format Implementation Guide v1.2. As previously noted, prescribers
would still be able to be able to create unstructured Sigs through the
use of the free text field, and our proposal only discusses the
capability of technology to enable a user to enter, receive, and
transmit codified Sig instructions using the NCPDP Structured and
Codified Sig Format.
---------------------------------------------------------------------------
\97\ http://www.ncpdp.org/NCPDP/media/pdf/SCRIPTImplementationRecommendationsV1-29.pdf.
---------------------------------------------------------------------------
Medication Dosing
In the Voluntary Edition proposed rule, we solicited comment on
whether we should propose health IT certification for oral liquid
medication dosing to the metric standard (e.g., mL or milliliters) for
patient safety reasons (79 FR 10926-10927). Use of the metric standard
offers more precision in medication dose than the Imperial standard
(e.g., teaspoons), which can decrease preventable adverse drug events.
A number of health care and standards developing organizations,
including the AAP \98\ and NCPDP,\99\ support the use of the metric
standard for dosing volumetric medications. Additionally, the FDA's
Safe Use Initiative is working with CDC, NCPDP, and other stakeholders
to encourage adoption of the NCPDP's recommendations for standardizing
dosing designations on prescription container labels of oral liquid
medications.\100\ Recent research has demonstrated that parents who
used milliliter-only dosing instruments were less likely to make dosing
errors than parents who used teaspoons or tablespoon units.\101\
---------------------------------------------------------------------------
\98\ AAP Council on Clinical Information Technology Executive
Committee, 2011-2012. Policy Statement--Electronic Prescribing in
Pediatrics: Toward Safer and More Effective Medication Management.
Pediatrics 2013; 131;824.
\99\ http://www.ncpdp.org/NCPDP/media/pdf/wp/DosingDesignations-OralLiquid-MedicationLabels.pdf.
\100\ http://www.fda.gov/Drugs/DrugSafety/SafeUseInitiative/ucm188762.htm#overdoses.
\101\ Unit of Measurement Used and Parent Medication Dosing
Errors. Pediatrics 134:2 August 1, 2014. Pp. e354-e361.
---------------------------------------------------------------------------
We received a number of comments to the comment solicitation. Many
commenters noted that the structured Sig segment of the NCPDP SCRIPT
Standard v10.6 supports use of the metric standard for liquid
medication dosing. One ONC-ACB commented that in their experience,
vendors have struggled to properly codify medication dosing information
within the C-CDA in terms of consistency across all health IT systems.
Many provider organizations and patient advocacy organizations were in
support of requiring use of the metric standard for oral liquid
medication dosing. Additionally, many commenters were in favor of
providing the metric standard as one option to record liquid medication
doses. We also received comments recommending the proper use of leading
and trailing zeroes in dosing designations. NCPDP has recommended that
dose amounts should always use leading zeroes before the decimal point
for amounts less than one, and should not use trailing zeroes after a
decimal point for oral liquid medications.\102\
---------------------------------------------------------------------------
\102\ http://www.ncpdp.org/NCPDP/media/pdf/wp/DosingDesignations-OralLiquid-MedicationLabels.pdf.
---------------------------------------------------------------------------
Our intent is for health IT to be able to more precisely dose
prescriptions in order to reduce dosing errors and improve patient
safety. We also believe that use of the metric standard could improve
patient safety and potentially reduce dosing errors for all medications
in addition to oral liquid medications. We therefore propose, for
certification to this criterion, that a Health IT Module be capable of
limiting a user's ability to electronically prescribe all medications
in only the metric standard. Prescription labels contain the dosing
instructions specified by the prescriber. Thus, if the prescriber doses
using the metric standard, the label will contain dosing instructions
in the metric standard and potentially reduce dosing errors during
administration. We also propose to require that a Health IT Module be
capable of always inserting leading zeroes before the decimal point for
amounts less than one when a user electronically prescribes medications
as well as not allow trailing zeroes after a decimal point. We welcome
comment on these proposals, including the feasibility of implementing
the metric standard for e-prescribing all medications.
Incorporate Laboratory Tests and Values/Results
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(4) (Incorporate laboratory tests and values/results)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``incorporate laboratory tests
and values/results'' certification criterion that is revised in
comparison to the 2014 Edition ``incorporate laboratory tests and
values/results'' criterion (Sec. 170.314(b)(5)). We propose to adopt
and include the HL7 Version 2.5.1 Implementation Guide: S&I Framework
Lab Results Interface, Draft Standard for Trial Use, Release 2, US
Realm (``LRI Release 2'') in the proposed 2015 Edition ``transmission
of laboratory test reports'' criterion for the ambulatory setting. LRI
Release 2 is currently under ballot reconciliation with HL7 and should
be published in the next few months.\103\ LRI Release 2 would:
---------------------------------------------------------------------------
\103\ http://www.hl7.org/participate/onlineballoting.cfm?ref=nav#nonmember. Access to the current draft
of the LRI Release 2 IG is freely available for review during the
public comment period by establishing an HL7 user account.
---------------------------------------------------------------------------
Implement common formats across US Realm IGs for
consistent reader
[[Page 16838]]
experience (e.g., sequence of sections, formatting, layout, and
terminology);
Incorporates all previous errata, LRI Release 1 DSTU
comments and change requests;
Adopt HL7 version 2.8 fields developed to fill gaps
identified in the development of Release 1;
Include harmonized data type ``flavors'' for use across
the US Realm Lab IGs;
Introduce initial requirements for error reporting
conditions and severity (hard/soft errors) and system/application
acknowledgements;
Harmonize data element usage and cardinality requirements
with LOI Release 1, and the electronic Directory of Services (eDOS) IG;
Incorporate US Lab Realm value sets developed for clarity
and consistency across all laboratory IGs; and
Use a new publication method for value sets that allows
for precision usage at point of use and provides ``at a glance''
comprehensive usage at the field and component-level across all
laboratory IGs; and synced with value set activities (HL7, VSAC, etc.).
Overall, we propose to adopt LRI Release 2 because it addresses
errors and ambiguities found in LRI Release 1 and harmonizes
interoperability requirements with other laboratory standards we
propose to adopt in this proposed rule (e.g., the HL7 Version 2.5.1
Implementation Guide: S&I Framework Laboratory Orders from EHR, DSTU
Release 2, US Realm, 2013 \104\).
---------------------------------------------------------------------------
\104\ We have proposed to adopt this implementation guide for
the 2015 Edition ``CPOE for laboratory orders'' certification
criterion.
---------------------------------------------------------------------------
As compared to the 2014 Edition certification criterion, we also
propose more specific requirements for how a Health IT Module must be
capable of electronically displaying the information included in a test
report. This specificity would improve the consistency with how
laboratory tests and values/results are displayed, which would also
assist with laboratory compliance with CLIA. To meet this criterion, a
Health IT Module would be required to display the following information
included in laboratory test reports it receives: (1) the information
for a test report as specified in 42 CFR 493.1291(a)(1) through (a)(3)
and (c)(1) through (c)(7); the information related to reference
intervals or normal values as specified in 42 CFR 493.1291(d); the
information for alerts and delays as specified in 42 CFR 493.1291(g)
and (h); and the information for corrected reports as specified in 42
CFR 493.1291(k)(2).
We also propose, for the purposes of certification, to require a
Health IT Module to be able to use, at a minimum, the version of
Logical Observation Identifiers Names and Codes (LOINC[supreg]) adopted
at Sec. 170.207(c)(3) (version 2.50) as the vocabulary standard for
laboratory orders. This is the most recent version of LOINC[supreg]. We
refer readers to section III.A.2.d (``Minimum Standards'' Code Sets)
for further discussion of our adoption of LOINC[supreg] as a minimum
standards code set and our proposal to adopt version 2.50, or
potentially a newer version if released before a subsequent final rule,
as the baseline for certification to the 2015 Edition.
We propose to adopt the updated LRI Release 2 at Sec.
170.205(j)(2), which requires the modification of the regulatory text
hierarchy in Sec. 170.205(j) to designate the standard referenced by
the 2014 Edition version of this certification criterion at Sec.
170.205(j) to be at Sec. 170.205(j)(1). This regulatory structuring of
the IGs would make the CFR easier for readers to follow.
EHR-S Functional Requirements LRI IG/Testing and Certification
Requirements
We seek comment on the HL7 EHR-S Functional Requirements for the
V2.5.1 Implementation Guide: S&I Framework Lab Results Interface R2,
Release 1, US Realm, Draft Standard for Trial Use, Release 1 (``EHR-S
IG''). The EHR-S IG is currently under ballot reconciliation with
HL7.\105\ The focus of the EHR-S IG is the definition of EHR system
functional requirements related to the receipt of laboratory results
that are compliant with the LRI Release 2. The EHR-S IG also includes
additional requirements as set forth in CLIA as well as clinical best
practices beyond the scope of LRI Release 2.
---------------------------------------------------------------------------
\105\ http://www.hl7.org/participate/onlineballoting.cfm?ref=nav#nonmember. Access to the current draft
of the EHR-S IG is freely available for review during the public
comment period by establishing an HL7 user account.
---------------------------------------------------------------------------
We specifically seek comment on the clarity and completeness of the
EHR-S IG in describing the requirements related to the receipt and
incorporation of laboratory results for measuring conformance of a
Health IT Module to LRI Release 2. In addition, we seek comment on how
a Health IT Module should be tested and certified consistently and
uniformly for the incorporation of laboratory results data. For
example, should testing and certification require the Health IT Module
to demonstration the ability to associate the laboratory result with an
order or patient, to recall the result for display or for submission to
another technology, and/or to use the result for automated clinical
decision support interventions? Further, what, if any, specific
capabilities currently included in the EHR-S IG should be part of
testing and certification for this criterion?
Transmission of Laboratory Test Reports
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(5) (Transmission of laboratory test reports)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``transmission of laboratory
test reports'' certification criterion that is revised in comparison to
the 2014 Edition ``transmission of electronic laboratory tests and
values/results to ambulatory providers'' criterion (Sec.
170.314(b)(6)). We have renamed this criterion to more clearly indicate
its availability for the certification of health IT used by any
laboratory. We propose to adopt and include the HL7 Version 2.5.1
Implementation Guide: S&I Framework Lab Results Interface, Draft
Standard for Trial Use, Release 2, US Realm (``LRI Release 2'') in the
proposed 2015 Edition ``transmission of laboratory test reports''
criterion. LRI Release 2 is currently under ballot reconciliation with
HL7 and should be published in the next few months.\106\ We propose to
adopt this standard for the same reasons discussed in the 2015 Edition
``incorporate laboratory tests and values/results'' above. We refer
readers to the description of the LRI Release 2 IG and our rationale
for its adoption discussed in that criterion.
---------------------------------------------------------------------------
\106\ Access to the current draft of the LRI Release 2 IG is
freely available for review during the public comment period by
establishing an HL7 user account.
---------------------------------------------------------------------------
As also discussed in the 2015 Edition ``incorporate laboratory
tests and values/results'' above, the LRI Release 2 IG requires the
information for a test report as specified at 42 CFR 493.1291(a)(1)
through (3), (c)(1) through (c)(7), (d), (g), (h) and (k)(2) to be
included in the content message. Therefore, inclusion of this standard
for certification should not only facilitate improved interoperability
of electronically sent laboratory test reports (as discussed in more
detail in the 2015 Edition ``incorporate laboratory tests and values/
results'' criterion), but also facilitate laboratory compliance with
CLIA as it relates to the incorporation and display of test results in
a receiving system.
We also propose, for the purposes of certification, to require a
Health IT
[[Page 16839]]
Module to be able to use, at a minimum, the version of Logical
Observation Identifiers Names and Codes (LOINC[supreg]) adopted at
Sec. 170.207(c)(3) (version 2.50) as the vocabulary standard for
laboratory orders. This is the most recent version of LOINC[supreg]. We
refer readers to section III.A.2.d (``Minimum Standards'' Code Sets)
for further discussion of our adoption of LOINC[supreg] as a minimum
standards code set and our proposal to adopt version 2.50, or
potentially a newer version if released before a subsequent final rule,
as the baseline for certification to the 2015 Edition.
We propose to adopt the updated LRI Release 2 at Sec.
170.205(j)(2), which requires the modification of the regulatory text
hierarchy in Sec. 170.205(j) to designate the standard referenced by
the 2014 Edition version of this certification criterion at Sec.
170.205(j) to be at Sec. 170.205(j)(1). This regulatory structuring of
the IGs would make the CFR easier for readers to follow.
Data Portability
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(6) (Data portability)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``data portability''
certification criterion that is revised in comparison to the 2014
Edition ``data portability'' certification criterion (Sec.
170.314(b)(7)). Similar to the 2014 Edition version, we propose to
include the 2015 Edition ``data portability'' criterion in the Base EHR
definition (i.e., the 2015 Base EHR definition).
For the 2014 Edition ``data portability'' criterion, we expressed
that the criterion was intended to enable an EP, eligible hospital, or
CAH to create a set of export summaries for all patients in EHR
technology formatted according to the C-CDA that includes each
patient's most recent clinical information. (77 FR 54193). We also
included this criterion in the Base EHR definition as a way to ensure
that the capability was delivered to EPs, eligible hospitals, or CAHs.
By including the criterion in the Base EHR definition, an EP, eligible
hospital, or CAH must have EHR technology certified to this criterion
in order to possess EHR technology that meets the CEHRT definition.
In the years since the 2014 Edition final rule was issued
(September 2012) and the subsequent implementation and use of this
capability by EPs, eligible hospitals, and CAHs, we have received two
types of feedback. From health IT developers, we have received requests
for clarification about this certification criterion's scope. For
example, requests for clarifications about the data that must be
produced and from how far back in time the data must be produced.
Whereas from providers (and the implementation professionals and third
party developers with which they work), we have generally received more
substantive critiques about the overall usefulness of the capability
and the ways in which health IT developers met the certification
criterion's requirements but did not necessarily deliver on its intent.
Such ``user'' comments conveyed that some health IT developers provided
a capability that was difficult or non-intuitive to use, difficult to
find to even use (e.g., ``hidden''), and in some cases either required
developer personnel to assist the provider in executing the capability
or limited its execution to only being done by the developer at the
provider's request. We have also received feedback that the scope of
testing has not rigorously assessed the ability of health IT to create
large quantities of export summaries. As a result, some providers have
reported challenges and poor performance associated with this
capability.
We believe that this feedback from CEHRT users indicates that the
data portability certification criterion adopted in the 2014 Edition
has not provided the data accessibility to providers we believed would
occur as a result of its adoption. It also indicates that some health
IT developers have (intentionally or unintentionally) obstructed the
certification criterion's true intent--to give providers easy access
and an easy ability to export clinical data about their patients for
use in a different EHR technology or even a third party system for the
purpose of their choosing.
To address provider critiques as well as to provide additional
developer requested clarity, we propose a revised 2015 Edition ``data
portability'' certification criterion as compared to the 2014 Edition
version. The proposed data portability certification criterion at Sec.
170.315(b)(6) approaches data portability from a slightly different
angle than the 2014 Edition version and focuses on the following
specific capabilities.
1. As a general rule, we emphasize that this capability would need
to be user-focused and user driven. A user must be able to set the
configuration options included within the more detailed aspects of the
criterion and a user must be able to execute these capabilities at any
time the user chooses and without subsequent developer assistance to
operate. We expect that testing of a Health IT Module presented for
certification to this criterion would include a demonstration that the
Health IT Module enables a user to independently execute this
capability without assistance from the health IT developer beyond
normal orientation/training.
2. The criterion would require that a user be able to configure the
Health IT Module to create an export summary for a given patient or set
of export summaries for as many patients selected. It would also
require that these export summaries be able to be created according to
any of the following document-template types included in the C-CDA R2.0
(also proposed as the content standard in this criterion): CCD;
Consultation Note; History and Physical; Progress Note; Care Plan;
Transfer Summary; and Referral Note. We also propose that the Discharge
Summary document template be included for a Health IT Module developed
for the inpatient setting.
3. From a data perspective, we propose that the minimum data that a
Health IT Module must be capable of including in an export summary are:
the data represented by the Common Clinical Data Set and:
Encounter diagnoses (according to the standard specified
in Sec. 170.207(i) (ICD-10-CM) or, at a minimum, the version of the
standard at Sec. 170.207(a)(4) (September 2014 Release of the U.S.
Edition of SNOMED CT[supreg]) \107\;
---------------------------------------------------------------------------
\107\ We refer readers to section III.A.2.d (``Minimum
Standards'' Code Sets) for further discussion of our adoption of
SNOMED CT[supreg] as a minimum standards code set and our proposal
to adopt the September 2014 Release (U.S. Edition), or potentially a
newer version if released before a subsequent final rule, as the
baseline for certification to the 2015 Edition.
---------------------------------------------------------------------------
Cognitive status;
Functional status;
For the ambulatory setting only. The reason for referral;
and referring or transitioning provider's name and office contact
information; and
For the inpatient setting only. Discharge instructions.
4. We propose that a user would need to be able to be able to
configure the technology to set the time period within which data would
be used to create the export summary or summaries. And that this must
include the ability to enter in a start and end date range as well as
the ability to set a date at least three years into the past from the
current date.
5. We propose that a user would need to be able to configure the
technology to create an export summary or summaries based on the
following user selected events:
A relative date or time (e.g., the first of every month);
[[Page 16840]]
A specific date or time (e.g., on 10/24/2015); and
When a user signs a note or an order.
6. We propose that a user would need to able to configure and set
the storage location to which the export summary or export summaries
are intended to be saved.
Again, we emphasize that all these capabilities would need to be
able to be configured and executed by a user without the aid of
additional health IT developer personnel and without the need to
request developer action. Further, we also reiterate that we have
expanded the nature and focus of this criterion to more precisely
address provided critiques as well as to expand the anticipated and
potential uses providers can deploy based on this more configuration
focused criterion.
Data Segmentation for Privacy
We propose to adopt two new certification criteria that would focus
on the capability to separately track (``segment'') individually
identifiable health information that is protected by rules that are
more privacy-restrictive than the HIPAA Privacy Rule. This type of
health information is sometimes referred to as sensitive health
information. The HIPAA Privacy Rule serves as the federal baseline for
health information privacy protections. It also generally permits the
use or disclosure of protected health information (PHI) for limited
specific purposes (such as treatment and payment) without a patient's
permission.\108\
---------------------------------------------------------------------------
\108\ http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/.
---------------------------------------------------------------------------
The HIPAA Privacy Rule does not override (or preempt) more privacy-
protective federal and state privacy laws. A number of federal and
state health information privacy laws and regulations are more privacy-
protective than the HIPAA Privacy Rule. Typically, these rules require
a patient's permission (often referred to as ``consent'' in these
rules) in writing in order for the individually identifiable health
information regulated by those laws to be shared. One example is the
Federal Confidentiality of Alcohol and Drug Abuse Patient Records
regulations (42 CFR part 2) (``part 2'') that apply to information
about treatment for substance abuse from federally funded
programs.\109\ There are also federal laws protecting certain types of
health information coming from covered U.S. Department of Veterans
Affairs facilities and programs (38 U.S.C. 7332). These laws and
comparable state laws were established, in part, to address the social
stigma associated with certain medical conditions by encouraging people
to get treatment and providing them a higher degree of control over how
their health information may be shared. These laws place certain
responsibilities on providers to maintain the confidentiality of such
information. More restrictive state laws also protect certain
categories of individually identifiable health information, such as
information regarding minors or teenagers, intimate partner/sexual
violence, genetic information, and HIV-related information.\110\ These
laws and regulations remain in effect and changes to these laws and
regulations are not within the scope of this proposed rule.\111\
However, with these laws in mind, the proposals that follow seek to
encourage the development and use of a technical capability that
permits users to comply with these existing laws and regulations. These
proposals are also in line with the Connecting Health and Care for the
Nation: A Shared Nationwide Interoperability Roadmap Version 1.0.\112\
HHS is committed to encouraging the development and use of policy and
technology to advance patients' rights to access, to amend, and to make
choices for the disclosure of their electronic individually
identifiable health information. HHS also noted support for the
development of standards and technology to facilitate patients' ability
to control the disclosure of specific information that is considered by
many to be sensitive in nature (such as information related to
substance abuse treatment, reproductive health, mental health, or HIV)
in an electronic environment.\113\
---------------------------------------------------------------------------
\109\ http://www.healthit.gov/sites/default/files/privacy-security/gwu-data-segmentation-final-cover-letter.pdf.
\110\ http://www.healthit.gov/providers-professionals/patient-consent-electronic-health-information-exchange/health-information-privacy-law-policy.
\111\ For a policy discussion, see Substance Abuse and Mental
Health Services Administration (SAMHSA)'s recent public listening
session pertaining to the federal confidentiality of regulations:
https://www.federalregister.gov/articles/2014/05/12/2014-10913/confidentiality-of-alcohol-and-drug-abuse-patient-records.
\112\ http://www.healthit.gov/sites/default/files/nationwide-interoperability-roadmap-draft-version-1.0.pdf.
\113\ http://www.healthit.gov/sites/default/files/nationwide-interoperability-roadmap-draft-version-1.0.pdf.
---------------------------------------------------------------------------
Technological advances are creating opportunities to share data and
allow patient preferences to electronically persist in health IT. In
2012, ONC launched the Data Segmentation for Privacy (DS4P) initiative
through ONC's Standards and Interoperability (S&I) Framework.\114\ The
DS4P initiative aimed to provide technical solutions and pilot
implementations to help meet existing legal requirements in an
increasingly electronic environment.\115\ The DS4P initiative worked to
enable the implementation and management of varying disclosure policies
in an electronic health information environment in an interoperable
manner. Overall, the DS4P initiative and its subsequent pilots focused
on the exchange of health information in the context of 42 CFR part 2
and sought to develop technical standards that would enable a provider
to adopt health IT that could segment electronic sensitive health
information regulated by more restrictive laws and make compliance with
laws like Part 2 more efficient. Since the sunset of the DS4P
initiative in April 2014, there have been live implementations and
public testimony regarding the success and practical application of the
DS4P standard. Organizations including the Substance Abuse and Mental
Health Services Administration (SAMHSA), the U.S. Department of
Veterans Affairs (VA), and private companies that participated in the
initiative have moved to production use of DS4P. For example, a
stakeholder who implemented the DS4P part 2 solution noted that the
DS4P technical capability implemented in parts of Florida has saved
some hospitals millions of dollars associated with the cost of care
because the patients they treat with substance use issues or behavioral
health issues were able to send an electronic referral and get a
discharge performed earlier in the process.\116\ Another technology
stakeholder incorporated the DS4P technical functionality into its
behavioral health and general hospital health IT solutions released
this year. Most recently, SAMHSA developed an open source technology
for patient consent management that uses the DS4P standard.\117\ In
September 2014, this technical solution was deployed into a live
environment at a public health department.
---------------------------------------------------------------------------
\114\ http://wiki.siframework.org/Data+Segmentation+for+Privacy+Use+Cases.
\115\ For more information about enabling privacy through data
segmentation technology, see http://www.healthit.gov/providers-professionals/enabling-privacy.
\116\ See Health IT Policy Committee's (HITPC) Privacy and
Security Tiger Team Public Meeting, Transcript, (Apr. 16, 2014), p.
14, http://www.healthit.gov/facas/sites/faca/files/PSTT_Transcript_Final_2014-04-16.pdf.
\117\ http://www.healthit.gov/providers-professionals/ds4p-initiative.
---------------------------------------------------------------------------
The technical specifications are outlined in the HL7 Version 3
Implementation Guide: DS4P, Release 1
[[Page 16841]]
(DS4P IG), Part 1: CDA R2 and Privacy Metadata.\118\ The DS4P IG
describes the technical means of applying security labels (privacy
metadata) which can be used to enact any security or privacy law,
regulation, or policy so that the appropriate access control decisions
will be made regarding downstream use, access or disclosure for
specially protected data so that appropriate metadata tags are applied.
---------------------------------------------------------------------------
\118\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=354. Completed Normative Ballot in
January 2014 and was successfully reconciled in February 2014. HL7
approved the final standard for publication and ANSI approved in May
2014.
---------------------------------------------------------------------------
Conceptually, the DS4P approach utilizes metadata applied in layers
(e.g. metadata applied to the header, section, or entry levels of a C-
CDA document). The DS4P technical approach defaults to privacy metadata
tagging at the document level. If an organization chooses to apply
additional privacy metadata tagging within a document, that optional
technical capability is also described within the IG for CDA. If a
receiving system is unable to process section or entry level privacy
metadata, the default is tagging at the document level. The approach
relies on certain electronic actions being taken by both the sending
system and the receiving system. The sending system must:
1. Identify information that requires enhanced protection or is
subject to further restrictions;
2. Verify that the patient's privacy consent decision allows for
the disclosure of health information; \119\ and
---------------------------------------------------------------------------
\119\ http://www.healthit.gov/providers-professionals/patient-consent-electronic-health-information-exchange.
---------------------------------------------------------------------------
3. Add privacy metadata to the health information being disclosed.
In turn, the receiving system must:
1. Be able to process the privacy metadata associated with the
received health information; and
2. Verify the patient's consent before re-disclosure, if the
receiving system has a need to re-disclose the information.
Data segmentation technology emerged to enable health care
providers' use of technology to comply with existing privacy laws,
regulations, and policies. The term ``data segmentation'' is often used
to describe the electronic labeling or tagging of a patient's health
information in a way that allows patients or providers to
electronically share parts,\120\ but not all, of a patient record. For
example, data segmentation technology can be applied to the sharing of
electronic sensitive health information, because that information is
afforded greater protections under various state and federal laws,\121\
as is discussed above. In this proposed rule, we propose to offer two
certification criteria that would allow for health IT to be presented
for testing and certification to the DS4P standard. We view the
proposed offering of certification to these criteria as an initial step
on technical standards towards the ability of an interoperable health
care system to compute and persist the applicable permitted access, use
or disclosure; whether regulated by state or federal laws regarding
sensitive health information or by an individual's documented choices
about downstream access to, or use or disclosure to others of, the
identifiable individual's health information. The application of the
DS4P standard at the document level is an initial step. We understand
and acknowledge additional challenges surrounding the prevalence of
unstructured data, sensitive images, and potential issues around use of
sensitive health information by CDS systems. The adoption of document
level data segmentation for structured documents will not solve these
issues, but will help move technology in the direction where these
issues can be addressed.
---------------------------------------------------------------------------
\120\ The HL7 approved standard does allow for tagging at the
data element level, but this proposed rule is suggesting just
applying the DS4P to the document level.
\121\ http://www.healthit.gov/providers-professionals/patient-consent-electronic-health-information-exchange/health-information-privacy-law-policy.
---------------------------------------------------------------------------
For example, today, electronic sensitive health information is not
typically kept in the same repository as non-sensitive data. If
security labels were applied to C-CDA documents at the time they are
created (see ``data segmentation for privacy--send'' certification
criterion), the receiving system would have more choices about how to
store and use that sensitive information. If the receiving system had
the capability to grant access to the tagged documents by using the
security labels as part of the access control decision, then co-
mingling the tagged, sensitive health information with the non-
sensitive data becomes more achievable.
In July 2014, the HITPC provided recommendations on the use of DS4P
technology to enable the electronic implementation and management of
disclosure policies that originate from the patient, the law, or an
organization, in an interoperable manner, so that electronic sensitive
health information may be appropriately shared.\122\ The HITPC noted a
clear need to provide coordinated care for individuals with mental
health and/or behavioral health issues. The HITPC recognized that the
ability of patients to withhold consent to disclose information remains
a concern for providers. In particular, providers want to provide the
best care for patients, but they have concerns about incomplete records
due to both professional obligation and liability considerations. While
the need for providers to act on incomplete information is not
necessarily new, the use of health IT may create an expectation of more
complete information.\123\ In recognition of the consumer, business,
clinical, and technical complexities, the HITPC suggested a framework
of two glide paths for the exchange of 42 CFR part 2-protected data,
based on whether the subject is sending or receiving information.\124\
As a first step in the glide path, the HITPC recommended that we
include Level 1 (document level tagging) send and receive
functionality.\125\ Document level is the most basic level of privacy
metadata tagging described in the DS4P standard. The following two
proposals would implement the HITPC's recommendations.
---------------------------------------------------------------------------
\122\ See Health IT Policy Committee (HITPC) Recommendation
Letter to ONC, July 2014, http://www.healthit.gov/facas/sites/faca/files/PSTT_DS4P_Transmittal%20Letter_2014-07-03.pdf; see also
HITPC's Privacy and Security Tiger Team Public Meeting, Transcript,
May 12, 2014, http://www.healthit.gov/facas/sites/faca/files/PSTT_Transcript_Final_2014-05-12.pdf; Public Meeting, Transcript,
May 27, 2014, http://www.healthit.gov/facas/sites/faca/files/PSTT_Transcript_Final_2014-05-27.pdf.
\123\ Id.
\124\ For more details on the two glide paths for part 2-
protected data, see http://www.healthit.gov/facas/sites/faca/files/PSTT_DS4P_Transmittal%20Letter_2014-07-03.pdf.
\125\ Id. See also, related HITPC recommendations pertaining to
data segmentation submitted to ONC in September 2010: http://www.healthit.gov/sites/faca/files/hitpc_transmittal_p_s_tt_9_1_10_0.pdf.
---------------------------------------------------------------------------
Data Segmentation for Privacy--Send
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(7) (Data segmentation for privacy--send)
------------------------------------------------------------------------
A provider currently cannot send sensitive patient information
electronically without some technical capability to indicate
information is subject to restrictions, such as a prohibition on re-
disclosure without consent, consistent with 42 CFR part 2. The sending
provider also must have confidence that the receiver can properly
handle electronically sent 42 CFR part 2-covered data. Because neither
of these functionalities are currently supported in certification,
sensitive health information such as 42 CFR part 2-covered data is
often only
[[Page 16842]]
shared via paper and fax. We propose, consistent with the HITPC
recommendations, that for certification to this criterion, a Health IT
Module must be able to send documents using document level tagging
(Level 1) in accordance with the DS4P IG. Document level tagging
enables health IT to send the 42 CFR part 2-covered data along with the
appropriate privacy metadata tagging and keep it sequestered from other
data. The DS4P IG, which includes Level 1 functionality, provides
guidance to allow, with proper authorization, a system to send a C-CDA
with tags indicating any restrictions (such as a prohibition on re-
disclosure without consent). While the DS4P IG specifies the technical
means for applying privacy metadata tagging to C-CDA documents, it also
optionally supports use of privacy metadata tagging within the document
(at the section and entry levels). We only propose to require the
document level functionality for sending as part of certification to
this criterion.
Data Segmentation for Privacy--Receive
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(8) (Data segmentation for privacy--receive)
------------------------------------------------------------------------
In general, 42 CFR part 2-covered data is not currently provided
electronically to healthcare providers through electronic exchange.
Instead, the status quo remains to share 42 CFR part 2-covered data via
paper and fax. In line with the HITPC recommendations, we propose a
certification criterion that would require a Health IT Module to be
able to receive 42 CFR part 2-covered data in accordance with the DS4P
IG. DS4P at the document level (Level 1) of the recommendations allows
recipient health IT to receive, recognize, and view documents with
privacy metadata tagging indicating certain restrictions from 42 CFR
part 2 providers with the document sequestered from other health IT
data. A recipient provider could use document level tagging to
sequester the document from other documents received and help prevent
unauthorized re-disclosure, while allowing the sensitive data to flow
more freely to authorized recipients. Thus, consistent with the HITPC
recommendations, we propose that a Health IT Module be able to receive
documents tagged with privacy metadata tagging (Level 1).
Care Plan
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(b)(9) (Care plan)
------------------------------------------------------------------------
We propose to adopt a new 2015 Edition certification criterion that
would reflect a Health IT Module's ability to enable a user to record,
change, access, create and receive care plan information in accordance
with the ``Care Plan document template'' in the C-CDA Release 2.0
standard.
The S&I Framework Longitudinal Coordination of Care (LCC)
Longitudinal Care Plan Sub-Work Group defined a ``care plan'' as ``the
synthesis and reconciliation of the multiple plans of care produced by
each provider to address specific health concerns. It serves as the
blueprint shared by all participants to guide the individual's care. As
such, it provides the structure required to coordinate care across
multiple sites, providers, and episodes of care.'' \126\ The care plan
helps multiple providers and caregivers align and coordinate care,
which is especially valuable for patients living with chronic
conditions and/or disabilities. It also provides a structure to promote
the consideration of a patient's future goals and expectations in
addition to managing their currently active health issues.
---------------------------------------------------------------------------
\126\ http://wiki.siframework.org/file/view/Care%20Plan%20Glossary_v25.doc/404538528/Care%20Plan%20Glossary_v25.doc.
---------------------------------------------------------------------------
The C-CDA Release 2.0 contains a Care Plan document template that
reflects these principles and provides a structured format for
documenting information such as the goals, health concerns, health
status evaluations and outcomes, and interventions. Note that the Care
Plan document template is distinct from the ``Plan of Care Section'' in
previous versions of the C-CDA. The Care Plan document template
represents the synthesis of multiple plans of care (for treatment) for
a patient, whereas the Plan of Care Section represented one provider's
plan of care (for treatment). To make this distinction clear, the C-CDA
Release 2.0 has renamed the previous ``Plan of Care Section'' as the
``Plan of Treatment Section (V2).''
Given the value for improved coordination of care, we propose a new
2015 Edition certification criterion for ``care plan'' that would
require a Health IT Module to enable a user to record, change, access,
create, and receive care plan information in accordance with the ``Care
Plan document template'' in the HL7 Implementation Guide for
CDA[supreg] Release 2: Consolidated CDA Templates for Clinical
Notes.\127\ The IG provides guidance for implementing CDA documents,
including the Care Plan document template. The ``transitions of care''
certification criterion proposed elsewhere in this section of the
preamble would require a Health IT Module enable a user to send and
receive transitions of care/referral summaries according to the C-CDA
Release 2.0, which would include the Care Plan document template.
Therefore, this criterion would focus only on a Health IT Module's
ability to enable a user to record, change, access, create, and receive
care plan information. We welcome comment on our proposal, including
whether we should require certain ``Sections'' that are currently
deemed optional as part of the Care Plan document template for
certification to this criterion. For example, we invite comment on
whether we should require the optional ``Health Status Evaluations and
Outcomes Section'' and ``Interventions Section (V2)'' as part of
certification to this criterion, and if so, for what value/use case.
---------------------------------------------------------------------------
\127\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379.
---------------------------------------------------------------------------
Clinical Quality Measures--Record and Export
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(c)(1) (Clinical quality measures--record and export)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition certification criterion for
``clinical quality measures (CQM)--record and export'' that is revised
in comparison to the 2014 Edition ``CQM--capture and export''
certification criterion (Sec. 170.314(c)(1)). In order to align with
our use of the term ``record'' used in other 2014 and 2015 Edition
certification criteria, we propose to call this certification criterion
``CQM--record and export.'' We explain the term ``record'' in the 2014
Edition final rule at 77 FR 54168.\128\ We propose to require that a
system user be able to export CQM data at any time the user chooses and
without subsequent developer assistance to operate. We also propose to
require that this certification criterion be part of the set of
criteria necessary to satisfy the ``2015 Edition Base EHR'' definition
(see also section III.B.1 of this preamble for a discussion of the
proposed 2015 Edition Base EHR definition). Last, we solicit comment on
the version of standards we should adopt for this certification
criterion.
---------------------------------------------------------------------------
\128\ ``Record'' is used to mean the ability to capture and
store information in technology.
---------------------------------------------------------------------------
Standards for Clinical Quality Measures
In the 2014 Edition ``CQM--capture and export'' certification
criterion, we require that technology must be able to export a data
file formatted in
[[Page 16843]]
accordance with the HL7 Implementation Guide for CDA Release 2: Quality
Reporting Document Architecture (QRDA), DSTU Release 2 (July 2012)
standard. We understand that the industry is working to harmonize both
clinical quality measurement and CDS standards through initiatives such
as the Clinical Quality Framework (CQF) S&I initiative. CDS guides a
clinician to follow a standard plan of care, while CQMs measure
adherence to a standard plan of care. Thus, these two areas are closely
related and would benefit from standard ways to reference patient data
within health IT as well as common logic to define a sub-population.
The CQF S&I initiative is working to define a shared format,
terminology, and logic between CQMs and CDS for improved efficiency,
cost, and quality of care.
In order to harmonize CQM and CDS standards, the industry is using
pieces of existing CQM standards (e.g., Health Quality Measures Format
(HQMF), QRDA Categories I and III, and the Quality Data Model (QDM))
and CDS standards (e.g., Clinical Decision Support Knowledge Artifact
Specification (also known as HeD Schema) and the Virtual Medical
Record). HL7 issued an errata (September 2014) \129\ that reflects
updates based on an incremental version of the harmonized CQM and CDS
standards (i.e., QDM-based HQMF Release 2.1).\130\ This errata is meant
to be used in conjunction with the July 2012 QRDA IG we adopted in the
2014 Edition. Our understanding is that the fully harmonized CQM and
CDS standards will be based on the Quality Improvement and Clinical
Knowledge (QUICK) data model,\131\ and that the industry expects to
ballot a QUICK FHIR-based DSTU serving the same function as the HQMF
standard at the May 2015 HL7 meeting. Subsequent standards for
electronically processing and reporting CQMs and CDS would then be
expected to be built on the QUICK data model, including a QRDA-like
standard based on the anticipated QUICK FHIR-based DSTU.
---------------------------------------------------------------------------
\129\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=35. Please note that in order to access
the errata, the user should download the ``HL7 Implementation Guide
for CDA Release 2: Quality Reporting Document Architecture--Category
I, DSTU Release 2 (US Realm)'' package.
\130\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=97.
\131\ http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1045.
---------------------------------------------------------------------------
Given the timing of this proposed rule and the expected
deliverables for harmonized CQM and CDS standards as described above,
we solicit comment on the version of QRDA or the QRDA-like standards we
should adopt for this certification criterion. Specifically, we solicit
comment on the following three options:
HL7 Implementation Guide for CDA Release 2: Quality
Reporting Document Architecture (QRDA), DSTU Release 2 (July 2012);
HL7 Implementation Guide for CDA Release 2: Quality
Reporting Document Architecture (QRDA), DSTU Release 2 (July 2012) and
the September 2014 Errata; or
A QRDA-like standard based on the anticipated QUICK FHIR-
based DSTU.CQM standards we should adopt for this certification
criterion.
We anticipate that the QUICK data model will not be available to
review during the public comment period of this NPRM, and welcome
stakeholder input on the usefulness of adopting the current (July 2012)
QRDA standard alone or in conjunction with the September 2014 errata
given that we anticipate there will be harmonized CQM and CDS standards
available in mid-2015. We also seek to understand the tradeoffs
stakeholders perceive in adopting each standard provided that the EHR
Incentive Programs Stage 3 proposed rule is proposing that technology
certified to the 2015 Edition would not be required until January 1,
2018, but that technology certified to the 2015 Edition ``CQM--record
and export'' certification criterion would be needed for EPs, eligible
hospitals, and CAHs participating in the EHR Incentive Programs Stage 3
objectives and measures in 2017. Thus, we welcome input on recommended
QRDA standards for the ``CQM--record and export'' certification
criterion factoring in where the industry may be with adoption of CQM
and CDS standards over the next few years.
User Ability To Export CQM Data
We have received stakeholder feedback that some systems certified
to the 2014 Edition ``CQM--capture and export'' certification criterion
do not provide users with the ability to export data ``on demand'' nor
to export batches of multiple patients simultaneously. Rather, some
users of certified health IT must request this functionality from the
health IT developer. Our intent is that users should be able to export
CQM data formatted to the QRDA standard at any time the user chooses
for one or multiple patients and without additional assistance. Thus,
as proposed, when a Health IT Module is presented for certification to
this criterion, we would expect that testing of the Health IT Module
would include demonstration of a user's ability to export CQM data
without subsequent health IT developer assistance beyond normal
orientation/training.
Clinical Quality Measures--Import and Calculate
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criteria
Sec. 170.315(c)(2) (Clinical quality measures--import and calculate)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition certification criterion for
``clinical quality measures (CQM)--import and calculate'' that is
revised in comparison to the 2014 Edition ``CQM--import and calculate''
certification criterion (Sec. 170.314(c)(2)). We propose to require
that a system user be able to import CQM data at any time the user
chooses and without subsequent health IT developer assistance to
operate. We also no longer include an exemption that would allow a
Health IT Module presented for certification to all three CQM
certification criteria (Sec. Sec. 170.315(c)(1), (c)(2), and (c)(3))
to not have to demonstrate the data import capability. Last, we solicit
comment on our intended direction for testing and certifying health IT
and the version of standards we should adopt for this certification
criterion.
User Ability To Import CQM Data
We have received stakeholder feedback that some systems certified
to the 2014 Edition ``CQM--import and calculate'' certification
criterion do not provide users the ability to import data ``on
demand,'' and rather users must request this functionality from the
system developer or vendor. Our intent is that users should be able to
import CQM data formatted to the QRDA standard for one or multiple
patients at any time the user chooses and without additional
assistance. Thus, when a Health IT Module is presented for
certification to this criterion, we would expect that testing of the
Health IT Module would include demonstration of a user's ability to
import CQM data without subsequent health IT developer assistance
beyond normal orientation/training.
Import of CQM Data
For the 2014 Edition, we do not require systems that certify to
Sec. 170.314(c)(1) (CQM--capture and export), Sec. 170.314(c)(2)
(CQM--import and calculate), and Sec. 170.314(c)(3) (CQM--electronic
submission) to have to demonstrate that they can import data files in
accordance with the QRDA
[[Page 16844]]
standard. In 2012, we adopted this policy because we did not believe
that systems that could perform capture, export, and electronic
submission functions would need to import CQM data as they were in
essence ``self-contained'' (77 FR 54231). However, we have received
stakeholder input recommending that all systems should be able to
import CQM data and that there could be instances were a provider using
one technology to record CQM data could not subsequently import such
data into a different technology. We agree with this feedback.
Therefore, this exemption will no longer carry forward as part of the
proposed 2015 Edition version of this certification criterion. This
means that a Health IT Module presented for certification to this
certification criterion (Sec. 170.315(c)(2)) would need to be able to
demonstrate the ability to import data in order to be certified to this
certification criterion even if they also certify to provide ``record
and export'' and ``electronic submission/report'' functions.
Testing of Import and Calculate Functionalities
The testing procedures for the 2014 Edition ``CQM--import and
calculate'' certification criterion only test that technology can
import a small number of test records and use those for calculation of
CQM results. We have received feedback that technology should be able
to import a larger number of test records and that we should test this
ability to reflect real-world needs for technology. With the import of
a large number of records, technology also needs to be able to de-
duplicate records for accurate calculation of CQM results. Therefore
for testing and certification to the proposed 2015 Edition ``CQM--
import and calculate'' certification criterion, we intend for testing
to include that technology can import a larger number of test records
compared to testing for the 2014 Edition and automatically de-duplicate
them for accurate CQM calculation. We welcome comment on our proposed
intentions to test a larger number of test records compared to the 2014
Edition test procedure and that a Health IT Module could eliminate
duplicate records. We also request comment on the number of test
records we should consider testing a Health IT Module for performing
import and calculate functions.
Standards for Clinical Quality Measures
We describe above in the preamble for the proposed 2015 Edition
``CQM--record and export'' certification criterion our understanding of
the industry's timeline and expected deliverables for harmonized CQM
and CDS standards. Given the discussion above, we also solicit comment
on the QRDA standards we should consider adopting for this 2015 Edition
``CQM--import and calculate'' certification criterion.
Clinical Quality Measures--Report
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criteria
Sec. 170.315(c)(3) [Reserved]
------------------------------------------------------------------------
In the 2014 Edition, we adopted a ``CQM--electronic submission''
certification criterion that requires technology to enable a user to
electronically create a data file for transmission of CQM data in
accordance with QRDA Category I and III standards and ``that can be
electronically accepted by CMS'' (Sec. 170.314(c)(3)). We have
received stakeholder feedback recommending we better align our
certification policy and standards for electronically-specified CQM
(eCQM) reporting with other CMS programs that include eCQMs, such as
the Physician Quality Reporting System (PQRS) and Hospital Inpatient
Quality Reporting (IQR) programs. The PQRS and Hospital IQR programs
update their measure specifications on an annual basis through
rulemaking in the Physician Fee Schedule (PFS) and Inpatient
Prospective Payment Systems (IPPS) rules respectively.
To better align with the reporting requirements of other CMS
programs, we intend to propose certification policy for reporting of
CQMs in or with annual PQRS and/or Hospital IQR program rulemaking. We
anticipate we will propose standards for reporting of CQMs that reflect
CMS' requirements for the ``form and manner'' of CQM reporting (e.g.,
CMS program-specific QRDA standards), allowing for annual updates of
these requirements as necessary. Under this approach, the ``CQM--
report'' certification policy and associated standards for the 2015
Edition that support achieving EHR Incentive Program requirements would
be proposed jointly with the calendar year (CY) 2016 PFS and/or IPPS
proposed rules. We anticipate these proposed and final rules will be
published in CY 2015. We clarify that we anticipate removing
``electronic'' from the name of this certification criterion. As
described in the preamble, we expect that all functions proposed in the
2015 Edition certification criteria are performed or demonstrated
electronically. Thus, it is not necessary to specifically include this
requirement in the title of this certification criterion. We also
anticipate naming this certification criterion ``report'' instead of
``submission'' to better align with the language we use in other
certification criteria that also require demonstration of the same
functionality to submit data.
Clinical Quality Measures--Filter
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(c)(4) (Clinical quality measures--filter)
------------------------------------------------------------------------
We propose to adopt a new 2015 Edition certification criterion for
CQM filtering. In the Voluntary Edition proposed rule, we proposed a
new certification criterion that would require health IT to be able to
record structured data for the purposes of being able to filter CQM
results to create different patient population groupings by one or more
of a combination of certain patient characteristics \132\ (79 FR 10903-
04). We proposed this capability to support eCQM reporting where the
reporting entity is not an individual provider but rather a group
practice or an accountable care organization (ACO). We also proposed
certain patient characteristics that would support identification of
health disparities, help providers identify gaps in quality, and
support a provider in delivering more effective care to sub-groups of
their patients. We did not adopt this certification criterion in the
2014 Edition Release 2 final rule as we received comments recommending
we further refine the use cases and perform more analysis of which data
elements are being captured in standardized ways (79 FR 54462).
---------------------------------------------------------------------------
\132\ Practice site and address; Tax Identification Number
(TIN), National Provider Identifier (NPI), and TIN/NPI combination;
diagnosis; primary and secondary health insurance, including
identification of Medicare and Medicaid dual eligible; demographics
including age, sex, preferred language, education level, and
socioeconomic status.
---------------------------------------------------------------------------
CMS offers various options for providers to report quality data as
part of a group instead of individually reporting as individual
providers. For example, the PQRS offers the Group Practice Reporting
Option (GPRO) that allows for assessment and payment (or adjustment)
based on reporting of data on quality measures at the group level.
Similarly, there are group reporting options, including the GRPO under
the PQRS for reporting data used to assess quality for purposes of the
Value Modifier under the Medicare Physician Fee Schedule. Another CMS
group reporting option is the Comprehensive Primary Care (CPC)
initiative. In the CPC initiative, participating primary
[[Page 16845]]
care practices receive care management fees to support enhanced,
coordinated services. In the CPC initiative, each physical site
location is counted as a ``practice.'' A group practice may encompass
several primary care sites, of which some, but not all, are
participating in CPC. Because the unit of analysis in CPC is the
practice site, CMS requires all CPC participants to report CQMs at the
level of the practice rather than at the level of the individual
provider. Each CPC practice's quality results, which include
performance on patient experience and claims measures as well as CQMs,
are tied to the distribution of any Medicare shared savings calculated
and earned at the level of the Medicare population of each region
participating in the initiative.
ACO models and programs, such as the Medicare Shared Savings
Program (MSSP) and CMS Pioneer ACO Model, include groups of doctors,
hospitals, and other health care providers who come together
voluntarily to give coordinated high quality care to their patients. In
ACO models and programs, the providers that participate in the ACO
share responsibility for the care and outcomes of their patients. For
example, MSSP participants are rewarded if the ACO lowers the growth in
its health care costs while meeting performance standards on quality of
care. ACOs are required to internally report on cost and quality
metrics associated with the activities of their practitioners, to
promote the use of evidence-based medicine, and to support the care
coordination activities of their practitioners. Understanding the
practice patterns of individual practitioners for services provided on
behalf of the ACO is therefore important for such organizations.
In some cases, not all providers practicing at a particular
practice site location or in an ACO will be participating in the group
practice or ACO reporting options. The National Provider Identifier
(NPI) is insufficient by itself to attribute a provider's performance
to a particular group practice or ACO, as the provider could practice
in multiple health care organizations. Likewise, a health care
organization may have multiple Tax Identification Numbers (TINs).
Currently, data may be accessed by filtering on either the TIN or the
NPI, but not in combination due, in part, to current CMS reporting
requirements and limitations of health IT being used by providers. The
ability to filter by a combination of NPI/TIN could allow for more
specific and proper attribution of a provider's performance to the
correct organization for aggregating group practice or ACO quality
measure results.
Health IT should support an organization's ability to filter both
individual patient level and aggregate level eCQM results by data that
would support administrative reporting as well as identification of
health disparities and gaps in care for patients being treated at
particular group practice sites or in a given ACO. We, therefore,
propose a new certification criterion for CQM filtering that would
require health IT to be able to record data (according to specified
standards, where applicable) and filter CQM results at both patient and
aggregate levels by each one and any combination of the following data:
TIN;
NPI;
Provider type;
Patient insurance;
Patient age;
Patient sex in accordance with the standard specified in
Sec. 170.207(n)(1) (HL7 Version 3);
Patient race and ethnicity in accordance with the
standards specified in Sec. 170.207(f)(1) (OMB standard) and, at a
minimum, (f)(2) (``Race & Ethnicity--CDC'' code system in the PHIN
VADS);
Patient problem list data in accordance with, at a
minimum, the version of the standard specified in Sec. 170.207(a)(4)
(September 2014 Release of the U.S. Edition of SNOMED CT[supreg]); and
Practice site address.
We clarify that a Health IT Module must be able to filter by any
combination of the proposed data elements (i.e., by any one (e.g.,
provider type) or a combination of any of the data elements (e.g.,
combination of TIN and NPI or combination of all data)). We also note
that this combination requirement is different than other proposed
certification criteria in that it requires all combinations to be
demonstrated for certification and not just one. We anticipate that if
adopted, stakeholders may want to expand the list of data in this
certification criterion and support the reporting needs of additional
programs over time. Our intent with this proposal is to continue to
work with CMS and other stakeholders to ensure that this list of data
represents a common and relatively stable set across program needs in
support of program alignment.
For certain data elements, we have specified vocabulary standards
(as identified above) to maintain consistency in the use of adopted
national standards. As part of the 2014 Edition, technology is
certified to record patient race, ethnicity, and problem lists in
accordance with standards. In this proposed rule, for the
``demographics'' certification criterion and other criteria, we propose
to certify a Health IT Module to record patient sex, race, and
ethnicity in accordance with standards we propose to adopt as part of
the 2015 Edition. We also propose to certify a Health IT Module to the
record patient problem lists in accordance with the latest version of
the SNOMED CT[supreg] standard. Please refer to the proposed
``demographics'' and ``problem list'' certification criteria discussed
earlier in this section of the preamble for a more detailed discussion
about the standards. We are also aware that patient sex, race, and
ethnicity are being collected as supplemental data to the Quality
Reporting Data Architecture (QRDA) Category I and III files for eCQM
reporting to CMS. Collection of patient date of birth is currently
required as part of the 2014 Edition ``demographics'' certification
criterion, and is being proposed for the 2015 Edition ``demographics''
certification criterion. Therefore, we believe there should not be a
large developmental burden to enable a Health IT Module to record these
data because they are already being collected through policy
established in the 2014 Edition and/or are being proposed as part of
2015 Edition certification criteria discussed elsewhere in this
proposed rule.
We are aware that patient insurance can be collected using a payer
value set that denotes whether the patient has Medicare, Medicaid, and/
or another commercial insurance. We solicit comment on other payer
value sets that could be leveraged to support this proposal. We believe
that provider type could also inform quality improvement if there are
differences in quality measure results by different types of providers.
We are aware of the Healthcare Provider Taxonomy Code Set designed to
categorize the type, classification, and/or specialization of health
care providers.\133\ Health care providers applying for an NPI must
select a Healthcare Provider Taxonomy Code or code description during
the application process. We solicit comment on the appropriateness of
this code set for classifying provider types as well as other standards
that could be used classify provider types.
---------------------------------------------------------------------------
\133\ http://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/MedicareProviderSupEnroll/Taxonomy.html
---------------------------------------------------------------------------
In order to support the identification of CQM results for a
particular practice, we propose to include practice site address in the
list of data. We note that
[[Page 16846]]
while this information may not be needed for CQM filtering at the ACO
level, certification would require that health IT enables a user to
record practice site address, but not dictate that a user must include
this information. We believe the industry is aware of the need to
identify a standard way to represent address. While such a standard is
being developed, we believe that to support group or practice
reporting, having the address is one of the key data elements that
would allow a provider using health IT to filter CQM results at the
practice or group level. We solicit comment on standards for collecting
address data that could be leveraged to support this functionality.
We solicit comment on the appropriateness of the proposed data
elements for CQM filtering, including whether they are being captured
in standardized vocabularies. We also solicit comment on additional
data elements that we should consider for inclusion and standardized
vocabularies that might be leveraged for recording this information in
health IT.
Authentication, Access Control, and Authorization
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(1) (Authentication, access control, and authorization)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``authentication, access
control, and authorization'' certification criterion that is unchanged
in comparison to the 2014 Edition ``authentication, access control, and
authorization'' criterion (Sec. 170.314(d)(1)).
Auditable Events and Tamper-Resistance
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(2) (Auditable events and tamper-resistance )
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``auditable events and tamper-
resistance'' certification criterion that is unchanged in comparison to
the 2014 Edition ``auditable events and tamper-resistance'' criterion
(Sec. 170.314(d)(2)). We seek comment, however, on two issues. In
August 2014, the HHS Office of Inspector General (OIG) released a
report entitled ``The Office of the National Coordinator for Health
Information Technology's Oversight of the Testing and Certification of
Electronic Health Records.'' \134\ In that report, the OIG found that
ONC approved test procedures did not address common security issues,
including ``logging emergency access or user privilege changes.'' The
OIG therefore recommended ``. . . that ONC work with NIST to strengthen
EHR test procedure requirements so that the ATCBs [ONC-Authorized
Testing and Certification Bodies] can ensure that EHR vendors
incorporate common security and privacy features into the development
of EHRs.'' \135\
---------------------------------------------------------------------------
\134\ http://oig.hhs.gov/oas/reports/region6/61100063.pdf
\135\ http://oig.hhs.gov/oas/reports/region6/61100063.pdf
---------------------------------------------------------------------------
The standards adopted at Sec. 170.210(e) and referenced by the
2014 Edition ``auditable events and tamper-resistance'' and ``audit
report(s)'' certification criteria require that technology must be able
to record audit log information as specified in sections 7.2 through
7.4, 7.6 and 7.7 of the standard adopted at 45 CFR 170.210(h). The
standard adopted at Sec. 170.210(h) is ASTM E2147.\136\ Section 7.6 of
ASTM E2147 specifies that audit log content needs to include the ``type
of action'' and references six ``actions:'' Additions, deletions,
change, queries, print, and copy. Section 7.7 requires that the audit
log record when patient data is accessed. So while not explicitly
referenced in section 7.6, the action of ``access'' or viewing of a
patient's information is also required to be recorded for
certification. Moreover, we clarify that an ``emergency access'' event
is expected to be recorded (just like any other access) in accordance
with section 7.7.
---------------------------------------------------------------------------
\136\ http://www.astm.org/Standards/E2147.htm. The standard is
also incorporated by reference at 45 CFR 170.299(c)(1) and available
at the Office of the Federal Register.
---------------------------------------------------------------------------
Because it does not appear that the ASTM standard indicates
recording an event when an individual's user privileges are changed, we
seek comment on whether we need to explicitly modify/add to the overall
auditing standard adopted at 170.210(e) to require such information to
be audited or if this type of event is already audited at the point of
authentication (e.g., when a user switches to a role with increased
privileges and authenticates themselves to the system). We also seek
comments on any recommended standards to be used in order to record
those additional data elements.
In a 2013 report entitled ``Not All Recommended Safeguards Have
Been Implemented in Hospital EHR Technology (OEI-01-11-00570),'' \137\
the OIG recommended that ONC should propose a revision to this
certification criterion to require that EHR technology keep the audit
log operational whenever the EHR technology is available for updates or
viewing or, alternatively, CMS could update its meaningful use criteria
to require providers to keep the audit log operational whenever EHR
technology is available for updates or viewing.\138\ As a result of
that report, in the Voluntary Edition proposed rule, we proposed an
``auditable events and tamper resistance'' certification criterion that
would have required technology to prevent all users from being able to
disable an audit log. While several commenters supported the proposal,
an equal share expressed concern, including the HITSC. The HITSC
recommended against implementing this proposal, indicating that the
requirements of the 2014 Edition certification criterion (identifying
only a limited set of users that could disable the audit log and
logging when and by whom an audit log was disabled and enabled)
provided sufficient parameters to determine the accountable party in
the event of a security incident.\139\ Other commenters contended that
including an absolute prohibition would be problematic because there
are valid and important reasons for users to disable the audit log,
including allowing a system administrator to disable the audit log for
performance fixes, stability, disaster recovery, and system updates or
allowing a system administrator to disable it when there is rapid
server space loss which is hindering a provider from accessing needed
clinical information in a timely manner.
---------------------------------------------------------------------------
\137\ https://oig.hhs.gov/oei/reports/oei-01-11-00570.pdf.
\138\ https://oig.hhs.gov/oei/reports/oei-01-11-00570.pdf.
\139\ http://www.healthit.gov/FACAS/sites/faca/files/Baker_PSWG_2015editionnprm_public_comment_V2.pdf.
---------------------------------------------------------------------------
We reiterate our policy first espoused with the adoption of the
2014 Edition ``auditable events and tamper resistance'' certification
criterion in that the ability to disable the audit log must be
restricted to a limited set of users to meet this criterion. The
purpose of this certification criterion is to require health IT to
demonstrate through testing and certification that it has certain
security capabilities built in. As we have evaluated both OIG's input
and that of commenters, we believe our certification criterion is
appropriately framed within the parameters of what our regulation can
reasonably impose as a condition of certification. This regulation
applies to health IT and not to the people who use it. Thus, how an
individual provider or entity chooses to ultimately implement health IT
that has been certified to this or any other certification criterion
does so outside the scope of this regulation.
[[Page 16847]]
We also received feedback to the Voluntary Edition proposed rule
that there may be some events recorded in the audit log that may be
more critical to record than other events. Commenters noted that there
may be a critical subset of events that should remain enabled at all
times, while other events could be turned off during critical times or
for system updates by a subset of users. As noted above, the standards
adopted at Sec. 170.210(e) and referenced by the 2014 Edition
``auditable events and tamper-resistance'' certification criterion
requires that health IT technology must be able to record additions,
deletions, changes, queries, print, copy, access. The 2014 Edition also
required the log to record when the audit log is disabled and by whom
and that such capability must be restricted to a limited set of
identified users. As a result, we again seek comment on whether:
There is any alternative approach that we could or should
consider;
There is a critical subset of those auditable events that
we should require remain enabled at all times, and if so, additional
information regarding which events should be considered critical and
why; and
Any negative consequences may arise from keeping a subset
of audit log functionality enabled at all times.
Audit Report(s)
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(3) (Audit report(s))
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``audit reports(s)''
certification criterion that is unchanged in comparison to the 2014
Edition ``audit reports(s)'' criterion (Sec. 170.314(d)(3)).
Amendments
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(4) (Amendments)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``amendments'' certification
criterion that is unchanged in comparison to the 2014 Edition
``amendments'' criterion (Sec. 170.314(d)(4)). We note that this
certification criterion only partially addresses the amendment of
protected health information (PHI) requirements of 45 CFR 164.526.
Automatic Access Time-Out
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(5) (Automatic access time-out)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``automatic access time-out''
certification criterion that is unchanged (for the purposes of gap
certification) in comparison to the 2014 Edition ``automatic log-off''
criterion (Sec. 170.314(d)(5)). The 2014 Edition ``automatic log-off''
criterion requires a Health IT Module to ``prevent a user from gaining
further access to an electronic session after a predetermined time of
inactivity.'' In June 2014, the Privacy and Security Workgroup (PSWG)
of the HITSC assessed the automatic log-off criterion.\140\ While the
2014 Edition criterion refers to ``sessions,'' the PSWG noted the need
to recognize that many systems are not session-based. Instead, systems
may be stateless, clientless, and/or run on any device. The PSWG
further noted that the risk that this criterion addresses is the
potential that protected health information could be disclosed through
an unattended device. The HITSC recommended that this certification
criterion should not be overly prescriptive so as to inhibit system
architecture flexibility.
---------------------------------------------------------------------------
\140\ http://www.healthit.gov/facas/sites/faca/files/HITSC_PSWG_2015NPRM_Update_2014-06-17.pdf.
---------------------------------------------------------------------------
To clarify this intent and eliminate the reference to ``session,''
the PSWG suggested to the HITSC that this criterion by refined to state
``automatically block access to protected health information after a
predetermined period of inactivity through appropriate means until the
original user re-authenticates or another authorized user
authenticates.'' We agree in substance with the PSWG work and HITSC
recommendations. Accordingly, we propose a 2015 Edition ``automatic
access time-out'' certification criterion that reflects the HITSC
recommendations and the work of the PSWG. Specifically, the criterion
would require a Health IT Module to demonstrate that it can
automatically stop user access to health information after a
predetermined period of inactivity and require user authentication in
order to resume or regain the access that was stopped. We note,
however, that we do not believe this would have any impact on testing
and certification as compared to testing and certification to the 2014
Edition ``automatic log-off'' criterion (i.e., the 2015 ``automatic
access time-out'' criterion would be eligible for gap certification).
We welcome comments on this assessment.
Emergency Access
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(6) (Emergency access)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``emergency access''
certification criterion that is unchanged in comparison to the 2014
Edition ``emergency access'' criterion (Sec. 170.314(d)(6)).
End-User Device Encryption
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(7) (End-user device encryption)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``end-user device encryption''
certification criterion that is unchanged (for the purposes of gap
certification) in comparison to the 2014 Edition ``end-user device
encryption'' criterion (Sec. 170.314(d)(7)). We propose to require
certification to this criterion consistent with the most recent version
of Annex A: Approved Security Functions (Draft, October 8, 2014) for
Federal Information Processing Standards (FIPS) Publication 140-2.\141\
The purpose of this document is to provide a list of the approved
security functions applicable to FIPS PUB 140-2. To maintain and update
our certification requirements to the most recent NIST-approved
security functions, we propose to move to the updated version of Annex
A (Draft, October 8, 2014). We proposed to adopted this updated version
of Annex A at Sec. 170.210(a)(3). We note, however, that we do not
believe that this would have any impact on testing and certification as
compared to testing and certification to the 2014 Edition ``end-user
device encryption'' criterion (i.e., the 2015 ``end-user device
encryption'' criterion would be eligible for gap certification). We
welcome comments on this assessment.
---------------------------------------------------------------------------
\141\ http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf.
---------------------------------------------------------------------------
Integrity
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(8) (Integrity)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``integrity'' certification
criterion that is unchanged in comparison to the 2014 Edition
``integrity'' criterion (Sec. 170.314(d)(8)). However, we propose a
change in how a Health IT Module would be tested and certified to this
criterion. The 2011 and 2014 editions of this criterion have been
available for individual testing and certification. We propose that the
2015 Edition ``integrity'' criterion would be tested and certified to
support the context for which it was adopted--upon receipt of a summary
record in order to ensure the integrity of the information exchanged
[[Page 16848]]
(see Sec. 170.315(d)(8)(ii)). Therefore, we expect that this
certification criterion would most frequently be paired with the ToC
certification criterion for testing and certification.
In the 2014 Edition propose rule, we sought comment on whether we
should leave the standard for the 2014 Edition ``integrity''
certification criterion as SHA-1 \142\ or replace it with SHA-2,\143\
as SHA-2 is a much stronger security requirement. In the 2014 Edition
final rule (77 FR 54251), we determined that the SHA-1 standard should
serve as a floor and technology could be certified to the 2014 Edition
``integrity'' certification criterion if it included hashing algorithms
with security strengths equal to or greater than SHA-1. We also noted
that the Direct Project specification requires that SHA-1 and SHA-256
(one type of SHA-2 hash algorithms) be supported, which still remains
the case today.
---------------------------------------------------------------------------
\142\ http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf.
\143\ http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf.
---------------------------------------------------------------------------
It is our understanding that many companies, including Microsoft
and Google, plan to sunset (deprecate) SHA-1 no later than January 1,
2017.\144\ While the SHA-1 standard serves as the baseline standard for
certification to the proposed 2015 Edition ``integrity'' certification
criterion and health IT could be certified to a security strength
greater than SHA-1 (e.g., SHA-2), we seek comments on if, and when, we
should set the baseline for certification to the 2015 Edition
``integrity'' certification criterion at SHA-2. For example, we could
adopt and move to SHA-2 as the baseline certification requirement with
the effective date of a subsequent file rule. This would likely be in
late 2015 (considering the start of testing and certification), and
consistent with the current trajectory of the industry in this area.
Alternatively, we could set an effective date within the criterion for
when the baseline for certification would shift from SHA-1 to SHA-2
(e.g., beginning 2017).
---------------------------------------------------------------------------
\144\ http://www.symantec.com/en/au/page.jsp?id=sha2-transition.
---------------------------------------------------------------------------
Accounting of Disclosures
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(d)(9) (Accounting of disclosures)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``accounting of disclosures''
certification criterion that is unchanged in comparison to the 2014
Edition ``accounting of disclosures'' criterion (Sec. 170.314(d)(9)).
We note that the 2015 Edition criterion is no longer designated
``optional'' because such a designation is no longer necessary given
that we have discontinued the Complete EHR definition and Complete EHR
certification beginning with the 2015 Edition health IT certification
criteria.
View, Download, and Transmit to 3rd Party (VDT)
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(e)(1) (View, download, and transmit to 3rd party)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``VDT'' criterion that is
revised in comparison to the 2014 Edition ``VDT'' criterion (Sec.
170.314(e)(1)).
Clarified Introductory Text for 2015 Edition VDT Certification
Criterion
In the Voluntary Edition proposed rule, we proposed to make
clarifying changes to the introductory text at Sec. 170.315(e)(1) to
make it clear that this health IT capability is patient-facing and for
patients to use. Commenters generally supported clarifying the
introductory text of VDT. Commenters stressed the importance of
allowing authorized representatives the ability to perform the VDT
functionality. However, due to our approach to only finalize a subset
of modifications in the 2014 Edition Release 2 final rule, we chose not
to make that revision in the 2014 Edition Release 2 final rule.
Therefore, we again propose to revise the introductory text to lead
with ``Patients (and their authorized representatives) must be able to
use health IT to . . .'' We also propose to use this same phrase at the
beginning of each specific capability for VDT to reinforce this point.
We note that this proposed requirement included in this criterion does
not override an individual's right to access protected health
information (PHI) in a designated record set under 45 CFR 164.524.
Common Clinical Data Set, Updated C-CDA, and Diagnostic Image Reports
We propose to include an updated Common Clinical Data Set for the
2015 Edition that includes references to new and updated vocabulary
standards code sets. Please also see the Common Clinical Data Set
definition proposal in section III.B.3 of this preamble. For the same
reasons discussed in the proposed 2015 Edition ToC certification
criterion, we also propose to reference the updated version of the C-
CDA (Draft Standard for Trial Use, Release 2.0) for this certification
criterion; and note, for the reasons discussed under the 2015 ToC
certification criterion, compliance with Release 2.0 cannot include the
use of the ``unstructured document'' document-level template for
certification to this criterion.
We also propose that a Health IT Module must demonstrate that it
can make diagnostic image reports available to the patient in order to
be certified. A diagnostic imaging report contains a consulting
specialist's interpretation of image data. It is intended to convey the
interpretation to the referring (ordering) physician, and becomes part
of the patient's medical record. We believe it is important to include
this information in a patient's record to improve care. Therefore, we
propose to include diagnostic imaging reports in the certification
criterion as something a Health IT Module must be able to make
accessible to patients. Again, to prevent any misinterpretation, we
reiterate for stakeholders that this proposed rule and proposed
certification criterion apply to a Health IT Module with regard to what
must be demonstrated for the Health IT Module to be certified and does
not govern its use.
We request comment on whether we should require testing and
certification for the availability of additional patient data through
the view, download, transmit, and API (discussed below) capabilities.
For example, should patient data on encounter diagnoses, cognitive
status, functional status, or other information also be made available
to patients (or their authorized representatives) through these
capabilities? Additionally, similar to our proposals for the data
portability certification criterion, we request comment on including
requirements in this criterion to permit patients (or their authorized
representatives) to select their health information for, as applicable,
viewing, downloading, transmitting, or API based on a specific date or
time (e.g., on 10/24/2015), a period of time (e.g., the last 3 years),
or all the information available.
VDT--Application Access to Common Clinical Data Set
To complement the API capabilities in the proposed ``Application
Access to Common Clinical Data Set'' criterion at Sec. 170.315(g)(7),
which are intended to be used by health IT purchasers in the context of
providing application access to the Common Clinical Data Set, we also
propose to require that the same capabilities be met as part of the
2015 Edition VDT certification criterion. While in some respects it
could be argued that repeating these capabilities in the VDT
certification criterion are duplicative, we believe the contexts under
which the capabilities proposed by this criterion and proposed at
[[Page 16849]]
Sec. 170.315(g)(7) would be used and the contexts under which
certification to this criterion would be sought are distinct enough to
warrant this repetition (i.e., in some cases a health IT developer may
seek certification solely to this criterion). In recognition of the
fact that some health IT developers will choose to build a more tightly
integrated system that could rely on the same underlying capabilities
developed to meet Sec. 170.315(g)(7), we clarify that health IT
developers could provide the information necessary to satisfy the
``documentation'' and ``terms of use'' requirements in Sec.
170.315(e)(1)(iii)(D) and (E) of this criterion and Sec.
170.315(g)(7)(iv) and (v) only once so long as the information
addresses any potential technical differences in the application access
capabilities provided (e.g., a RESTful web service for Sec.
170.315(e)(1) versus a SOAP web service for Sec. 170.315(g)(7)). As
proposed as part of certification in conjunction with Sec.
170.315(g)(7), we similarly propose for this criterion to require ONC-
ACBs to submit a hyperlink (as part of a product certification
submission to the CHPL) that would allow any interested party to access
the API's documentation and terms of use. This hyperlink would first
need to be provided by the health IT developer to the ONC-ACB.
Including these capabilities in the VDT certification criterion
could address several aspects that currently pose challenges to
individuals (and their families) accessing their health information
(e.g., multiple ``portals''). Additionally, we have coordinated with
CMS to have the proposed meaningful use measure for VDT revised to
allow for responses to data requests executed by the API functionality
to count in the measure's numerator (please see the EHR Incentive
Programs Stage 3 proposed rule published elsewhere in this issue of the
Federal Register). This combination of technological capability and
measurement flexibility could enhance an individual's ability to
converge their data in the application of their choice. Furthermore, by
including these capabilities in this criterion, we ensure that health
IT developers who seek certification only to this criterion but not
(g)(7) because of their market focus, will equally be required to
include an API available as part of their technology.
We note that readers should also review the proposed ``API''
certification criterion in this section of the preamble for requests
for comments that may impact the finalization of the API proposal
included in this certification criterion. For example, we request
public comment on what additional requirements might be needed to
ensure the fostering of an open ecosystem around APIs so that patients
can share their information with the tools, applications, and platforms
of their own choosing.
Activity History Log
In the Voluntary Edition proposed rule, we proposed to include two
new data elements for the activity history log: transmission status and
addressee. Due to the approach we took with the 2014 Edition Release 2
final rule, we did not finalize either proposal. However, we received
support for our proposal to include the addressee as a data element in
the history log. Therefore, we propose to include ``addressee'' as a
new data element in the 2015 Edition VDT criterion related to the
activity history log. Although the 2014 Edition VDT criterion requires
that the action of ``transmit'' be recorded, we did not specify that
the intended destination be recorded. We believe this transactional
history is important for patients to be able to access, especially if a
patient actively transmits their health information to a 3rd party or
another health care provider.
Patient Access to Laboratory Test Reports
In February 2014, CMS, the CDC, and the Office for Civil Rights
(OCR) issued a final rule that addressed the interplay between the CLIA
rules, state laws governing direct patient access to their laboratory
test reports, and the HIPAA Privacy Rule.\145\ The final rule permits
laboratories to give a patient, a patient's ``personal
representative,'' or a person designated by the patient, as applicable,
access to the patient's completed test reports upon the patient's or
patient's personal representative's request.\146\ The final rule also
eliminated the exception under the HIPAA Privacy Rule to an
individual's right to access his or her protected health information
when it is held by a CLIA-certified or CLIA-exempt laboratory. While
patients can continue to get access to their laboratory test reports
from their doctors, these changes give patients a new option to obtain
their test reports directly from the laboratory while maintaining
strong protections for patients' privacy.
---------------------------------------------------------------------------
\145\ CMS is generally responsible for regulatory laboratory
oversight under CLIA, while CDC provides scientific and technical
advice to CMS related to CLIA and OCR administers the Health
Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy
Rule.
\146\ https://www.federalregister.gov/articles/2014/02/06/2014-02280/clia-program-and-hipaa-privacy-rule-patients-access-to-test-reports.
---------------------------------------------------------------------------
We seek to ensure that the test reports that are delivered by
providers to patients through the VDT capabilities adhere to the CLIA
test reporting requirements and, therefore, propose that a Health IT
Module presented for certification to this criterion must demonstrate
that it can provide patient laboratory test reports that include the
information for a test report specified in 42 CFR 493.1291(c)(1)
through (7); the information related to reference intervals or normal
values as specified in 42 CFR 493.1291(d); and the information for
corrected reports as specified in 42 CFR 493.1291(k)(2).
Web Content Accessibility Guidelines (WCAG)
We reaffirm for stakeholders that the proposed 2015 Edition VDT
criterion includes the WCAG 2.0 Level A (Level A) conformance
requirements for the ``view'' capability. This is the same requirement
we include in the 2014 Edition VDT criterion. We do, however, propose
to modify the regulatory text hierarchy at Sec. 170.204(a) to
designate this standard at Sec. 170.204(a)(1) instead of Sec.
170.204(a). This would also require the 2014 Edition VDT certification
criterion to be revised to correctly reference Sec. 170.204(a)(1). We
also seek comment on whether we should adopt WCAG 2.0 Level AA (Level
AA) conformance requirements for the ``view'' capability included in
the 2015 Edition VDT criterion (instead of Level A).
The most recent set of guidelines (WCAG 2.0) were published in 2008
\147\ and are organized under 4 central principles with testable
success criteria: Perceivable, Operable, Understandable, and Robust.
Each guideline offers 3 levels of conformance: A, AA, and AAA. Level A
conformance corresponds to the most basic requirements for displaying
Web content. Level AA conformance provides for a stronger level of
accessibility by requiring conformance with Level A success criteria as
well as Level AA specific success criteria. WCAG 2.0 Level AAA (Level
AAA) conformance comprises the highest level of accessibility within
the WCAG guidelines and includes all Level A and Level AA success
criteria as well as success criteria unique to Level AAA.
---------------------------------------------------------------------------
\147\ http://www.w3.org/TR/WCAG20/.
---------------------------------------------------------------------------
In the 2014 Edition final rule (77 FR 54179) we considered public
comment and ultimately adopted Level A for accessibility, but indicated
our interest in raising this bar over time. As part of the Voluntary
Edition proposed rule, we again proposed that health IT be compliant
with Level AA for the
[[Page 16850]]
proposed VDT certification criterion. We received a limited and mixed
response to this proposal (79 FR 54465). In particular, some health IT
developers opposed the increased level citing the cost and burden to
reach Level AA, while others supported the move and offered no
concerns. In both cases, health IT developers noted that WCAG
conformance tools are somewhat sparse and that they have had difficulty
finding viable tools.
Level AA provides a stronger level of accessibility and addresses
areas of importance to the disabled community that are not included in
Level A. For example, success criteria unique to Level AA include
specifications of minimum contrast ratios for text and images of text,
and a requirement that text can be resized without assistive technology
up to 200 percent without loss of content or functionality. We
recognize that Level AA is a step up from Level A, but also note that
is has been nearly 3 years since we adopted Level A for the purposes of
certification to the ``view'' capability. Accordingly, we once again
request comment on the appropriateness of moving to Level AA for
certification of the ``view'' capability included in the 2015 Edition
VDT certification criterion.
We understand that there are not separate guidelines for ``mobile
accessibility'' and that mobile is considered by the W3C Web
Accessibility Initiative to be covered by the WCAG 2.0 guidelines.\148\
Further, we would note that in September 2013, the W3C published a
working group note consisting of ``Guidance on Applying WCAG 2.0 to
Non-Web Information and Communications Technologies (WCAG2ICT).'' \149\
We again request public comment (especially from health IT developers
that have sought or considered certification to the 2014 Edition VDT
certification criterion with a ``non-web'' application) on what, if
any, challenges exist or have been encountered when applying the WCAG
2.0 standards.
---------------------------------------------------------------------------
\148\ http://www.w3.org/WAI/mobile/.
\149\ http://www.w3.org/TR/wcag2ict/.
---------------------------------------------------------------------------
``Transmit'' Request for Comment
In the 2014 Edition Release 2 final rule, we modified the
``transmit'' portion of the 2014 Edition VDT certification criterion to
consistently allow for C-CDA ``content'' capabilities to be separately
certified from ``transport'' capabilities using Direct. In so doing, we
modified the transmit portion of the certification criterion to allow
it to be met in one of two ways: (1) Following the Direct Project
specification (for HISPs); or (2) following the Edge Protocol IG. Given
this change to ``transmit'' that we have duplicated in the proposed
2015 Edition VDT certification criterion and our proposal to include an
API capability as part of the proposed 2015 Edition VDT certification
criterion, we request comment on whether stakeholders believe that it
would be beneficial to include the Direct Project's Implementation
Guide for Direct Project Trust Bundle Distribution specification \150\
as part of certification to the first way described above (following
the Direct Project specification (for HISPs)) for the 2015 Edition VDT
certification criterion. This trust bundle specification's focuses on
``guidance on the packaging and distribution of Trust Bundles to
facilitate scalable trust between Security/Trust Agents (STAs).'' As we
understand, including this specification as part of certification could
enable patient-facing technology to be configured to trust externally
hosted bundles of S/MIME certificates. In addition, we have continued
to hear concerns regarding the difficulties related to exchanging
Direct messages across platforms and ``trust communities'' in the
context of patient-directed transmissions. Therefore, we also request
comments on whether any additional requirements are needed to support
scalable trust between STAs as well as ways in which ONC, in
collaboration with other industry stakeholders, could support or help
coordinate a way to bridge any gaps.
---------------------------------------------------------------------------
\150\ http://wiki.directproject.org/file/view/Implementation+Guide+for+Direct+Project+Trust+Bundle+Distribution+v1.0.pdf.
---------------------------------------------------------------------------
C-CDA Creation Capability Request for Comment
We request public comment on a potential means to provide explicit
implementation clarity and consistency as well as to further limit
potential burdens on health IT developers. Specifically, should we
limit the scope of C-CDA creation capability within this certification
criterion to focus solely on the creation of a CCD document template
based on the C-CDA Release 2.0? This approach could also have the
benefit of creating clear expectations and predictability for other
health IT developers who would then know the specific document template
implemented for compliance with this criterion.
C-CDA Data Provenance Request for Comment
We refer readers to the request for comment under the same heading
(``C-CDA Data Provenance Request for Comment'') in the ToC
certification criterion earlier in this section of the preamble
(section III). The request for comment focuses on the maturity of the
HL7 IG for CDA Release 2: Data Provenance, Release 1 (US Realm) (DSTU)
\151\ and its potential use in connection with the C-CDA.
---------------------------------------------------------------------------
\151\ http://wiki.hl7.org/index.php?title=HL7_Data_Provenance_Project_Space and http://gforge.hl7.org/gf/project/cbcc/frs/?action=FrsReleaseBrowse&frs_package_id=240.
---------------------------------------------------------------------------
Clinical Summary
We note that we are not proposing a 2015 Edition ``clinical
summary'' certification criterion because past versions of this
certification criterion were adopted in direct support of the EHR
Incentive Programs. The proposals found in the EHR Incentive Programs
Stage 3 proposed rule published elsewhere in this issue of the Federal
Register rely on patients being provided with the ability to view,
download, and transmit their health information via online access.
Therefore, we believe the capabilities included in the 2015 Edition
``view, download, and transmit to 3rd party'' certification criterion
appropriately and sufficiently support the proposals of the EHR
Incentive Programs.
Secure Messaging
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(e)(2) (Secure messaging)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``secure messaging''
certification criterion that is unchanged in comparison to the 2014
Edition ``secure messaging'' criterion (Sec. 170.314(e)(3)).
Transmission to Immunization Registries
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(f)(1) (Transmission to immunization registries)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``transmission to immunization
registries'' certification criterion that is revised in comparison to
the 2014 Edition ``transmission to immunization registries'' criterion
(Sec. 170.314(f)(2)). We propose to adopt an updated IG, require
National Drug Codes (NDC) for recording administered vaccines, require
CVX codes for historical vaccines, and require a Health IT Module
presented for certification to
[[Page 16851]]
this criterion to be able to display an immunization history and
forecast from an immunization registry. These proposals are described
in more detail below.
Implementation Guide for Transmission to Immunization Registries
The 2014 Edition certification criterion for transmission to
immunization registries at Sec. 170.314(f)(2) references the following
IG for immunization messaging: HL7 Version 2.5.1: Implementation Guide
for Immunization Messaging, Release 1.4. Since the publication of the
2014 Edition final rule, the CDC has issued an updated IG (HL7 Version
2.5.1: Implementation Guide for Immunization Messaging, Release 1.5)
(October 2014) that promotes greater interoperability between
immunization registries and health IT. Release 1.5 focuses on known
issues from the previous release and revises certain HL7 message
elements to reduce differences between states and jurisdictions for
recording specific data elements. Specifically, Release 1.5: \152\
---------------------------------------------------------------------------
\152\ http://www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide-1-5-2014-11.pdf.
---------------------------------------------------------------------------
Is organized into profiles, including separate profiles
for VXU and ACK (acknowledgement) messages;
Clarifies and tightens conformance statements;
Corrects ACK (acknowledgment) messages to support improved
messaging back to the EHR about the success/failure of a message; and
Includes query and response changes such as V2.7.1 MSH
user constraints, minimum requirements for a response message, and
corrected profiles for response to errors and no match situations.
We believe these improvements are important to the IG and will
continue to support our ultimate goal for this certification
criterion--bidirectional immunization data exchange. Given the
improvements included in the updated IG, we propose to adopt it at
Sec. 170.205(e)(4) and include it in the 2015 Edition ``transmission
to immunization registries'' certification criterion.
National Drug Codes for Administered Vaccinations
In the Voluntary Edition proposed rule, we solicited comment for
future editions on whether we should replace CVX codes for representing
vaccines with NDC codes,\153\ and on options for recording historical
immunizations (79 FR 10908-9). NDC codes offer a number of benefits
compared to CVX codes because:
---------------------------------------------------------------------------
\153\ http://www.fda.gov/drugs/informationondrugs/ucm142438.htm.
---------------------------------------------------------------------------
They can support pharmaceutical inventory management
within immunization registries and are built into the provider's
workflow;
Are built into 2D barcodes, which have been successfully
piloted for vaccines, and can improve quality and efficiency of data
entry of information such as vaccine lot and expiration date; and
Can improve patient safety with better specificity of
vaccine formulation.
NDC codes also include packaging information as well as support
linking to the unit of use and sale, whereas CVX codes do not provide
this information as efficiently. These data elements are important for
supporting vaccine inventory management.
Immunization registries are tightly linked to inventory management
functions. This is largely due to the administration of the Vaccines
for Children (VFC) program, a federally funded program that provides
vaccines at no cost to children who might not otherwise be vaccinated
because of inability to pay. CDC purchases vaccines at a discount and
distributes them to grantees, which are state health departments and
local and territorial public health agencies. The grantees distribute
the VFC vaccines at no charge to private providers' offices and public
health clinics registered as VFC providers. Because of the way this
program is administered, immunization registries, which are maintained
by public health agencies, have been developed to include vaccine
inventory functions that help the grantees and providers manage their
VFC vaccine stock. Due to the coupling of inventory functions within
registries, many systems that can transmit immunization information to
registries are also able to support these inventory management
functions. NDC codes are used by many immunization registries to order
vaccines and for inventory purposes.
We believe NDC codes for vaccines may be best suited to support
immunization inventory management, as well as for providing the
benefits stated above for 2D barcoding and patient safety. Both the HL7
Version 2.5.1: Implementation Guide for Immunization Messaging, Release
1.5 and the C-CDA Release 2.0 IG support coding of immunizations using
both CVX and NDC codes. CDC also provides a publicly available mapping
of NDC codes for vaccines to CVX codes.\154\
---------------------------------------------------------------------------
\154\ http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=ndc. See also: http://www2a.cdc.gov/vaccines/iis/iisstandards/ndc_tableaccess.asp.
---------------------------------------------------------------------------
NDC codes for vaccines include a portion that identifies the
product, and thus cannot be used to code historical vaccinations of
unknown formulation. Historical vaccinations are self-reported
vaccinations given prior to the office visit. Patients can report
historical vaccinations to providers without supporting documentation,
such as a written or electronic vaccination history, and therefore the
provider does not know the manufacturer and/or formulation of the
product. In terms of options for recording historical vaccinations of
unspecified/unknown formulation, we solicited comments on two options
in the Voluntary Edition proposed rule:
Option 1: Continue to use CVX codes for historical
vaccinations only;
Option 2: Use the NDC syntax and create a new value set
for the product portion of the code for vaccines of unspecified formula
(e.g., influenza vaccine of unspecified formula) for historical
vaccinations (resulting in an ``NDC-like'' code).
The majority of commenters were opposed to Option 2 for creating an
``NDC-like'' code. Commenters believed it would add complexity to
coding NDC codes and be burdensome to maintain in the long-term. We
agree with commenters and therefore believe Option 1 is a more viable
solution for recording historical vaccinations. We believe health IT
should be able to record historical vaccinations to provide the most
complete record possible for a provider to use in determining which
vaccines a patient may need.
We received comments that recommended we consider moving to
RxNorm[supreg] codes for immunizations. However, RxNorm[supreg] does
not support inventory management nor does it support recording
historical vaccinations. Therefore, we do not believe RxNorm[supreg] is
the best available option for coding vaccinations at this time.
We also received public comment that, in certain circumstances, NDC
codes can be reused. Commenters expressed concerned about potential
confusion for vaccine products when NDC codes are reused. In
consultation with FDA, we understand that FDA does not intend to allow
reuse of NDC codes for vaccine products going forward. Thus, we do not
believe that reuse of NDC codes will be an issue for vaccine coding.
Given the discussion above on the benefits of NDC codes for coding
vaccinations and in consideration of public comment, we propose to
require for certification that a Health IT Module be able to
electronically create
[[Page 16852]]
immunization information for electronic transmission to immunization
registries using NDC codes for vaccines administered (i.e., the
National Drug Code Directory--Vaccine Codes, updates through January
15, 2015 \155\). For historical vaccines, we propose to continue the
use of CVX codes and propose to adopt the HL7 Standard Code Set CVX--
Vaccines Administered, updates through February 2, 2015,\156\ as the
baseline version for certification to the 2015 Edition. We refer
readers to section III.A.2.d (``Minimum Standards'' Code Sets) for
further discussion of our proposal to adopt the National Drug Code
Directory--Vaccine Codes as a minimum standards code set and the
``January 15, 2015 version,'' or potentially a newer version if
released before a subsequent final rule, as the baseline for
certification to the 2015 Edition. We also refer readers to section
III.A.2.d (``Minimum Standards'' Code Sets) for further discussion of
our adoption of CVX codes as a minimum standards code set and our
proposal to adopt the ``February 2, 2015 version,'' or potentially a
newer version if released before a subsequent final rule, as the
baseline for certification to the 2015 Edition.
---------------------------------------------------------------------------
\155\ http://www2a.cdc.gov/vaccines/iis/iisstandards/ndc_tableaccess.asp.
\156\ http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx.
---------------------------------------------------------------------------
In addition to soliciting comments on this proposal, we solicit
comment on whether we should allow use of NDC codes for administered
vaccines as an option for certification, but continue to require CVX
codes for administered vaccines for the 2015 Edition. Allowing for
optional use of NDC codes for administered vaccines could provide
health IT developers and health care providers an implementation period
before we would consider requiring NDC codes for administered vaccines.
We also solicit comment on whether we should require CVX plus the HL7
Standard Code Set MVX--Manufacturers of Vaccines Code Set (October 30,
2014 version) \157\ as an alternative to NDC codes for administered
vaccines. MVX codes identify the manufacturer of a vaccine and support
recording the vaccine at the trade name level when paired with the CVX
code. MVX codes do not, however, independently include the trade name,
package, or unit of use/unit of sale. CVX codes plus MVX codes could
provide more information than CVX codes alone, but not as much
information as NDC codes. As part of this comment solicitation, we also
invite comments on the implementation burden for health IT developers
and health care providers of requiring CVX plus MVX codes versus NDC
codes for administered vaccines.
---------------------------------------------------------------------------
\157\ http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=mvx.
---------------------------------------------------------------------------
Immunization History and Forecast
In the Voluntary Edition proposed rule, we solicited comment on the
maturity of bidirectional immunization data exchange activities and
whether we should propose to include bidirectional immunization
exchange in our certification rules. Commenters supported inclusion of
bidirectional immunization data exchange. We understand that the HL7
Version 2.5.1: Implementation Guide for Immunization Messaging, Release
1.5 we are proposing to adopt for this criterion provides improvements
that support bidirectional exchange between health IT and immunization
registries, including segments for querying a registry, receiving
information, and sending a response to the registry. Additionally, we
received comments specifically recommending that immunization forecast
information and CDS guidance provide results in accordance with the
Advisory Committee on Immunization Practice's (ACIP) \158\
recommendations.
---------------------------------------------------------------------------
\158\ http://www.cdc.gov/vaccines/acip/.
---------------------------------------------------------------------------
We believe that bidirectional exchange between health IT and
immunization registries is important for patient safety and improved
care. Immunization registries can provide information on a patient's
immunization history to complement the data in the EHR. Immunization
registries also provide immunization forecasting recommendations
according to the ACIP's recommendations. This information allows for
the provider to access the most complete and up-to-date information on
a patient's immunization history to inform discussions about what
vaccines a patient may need based on nationally recommended
immunization recommendations.
Provided the discussion above, we propose that, for certification
to this criterion, a Health IT Module would need to enable a user to
request, access, and display a patient's immunization history and
forecast from an immunization registry in accordance with the HL7
Version 2.5.1: Implementation Guide for Immunization Messaging, Release
1.5. We welcome comment on this proposal. We also welcome comments on
whether we should include an immunization history information
reconciliation capability in this criterion and the factors we should
consider regarding the reconciliation of immunization history
information.
Exchange of the Common Clinical Data Set--NDC and CVX Codes
For transmission of immunization information across settings using
the C-CDA standard, NDC codes carry more information than CVX codes,
specifically for inventory management and safety functions (e.g., trade
name, package, and unit of use/unit of sale). For quality reporting of
immunization coverage data using the QRDA Category I standard,
inventory management data may not be needed, and therefore a CVX code
is sufficient for submission of quality reporting data. However, ONC is
supportive of moving towards collection of vaccine administration data
within the EHR with the patient's clinical data regardless of the
requirements in the QRDA Category I standard. We believe it is
appropriate to use mapping from NDC codes to CVX codes and a mapping
table is available.\159\ We understand that the C-CDA Release 2.0 can
support NDC codes as a translational data element, but the CVX code is
required to accompany it. The additional information NDC codes contain
could assist with vaccine tracking for clinical trials and adverse
events. Therefore, we propose in a later section of this rule to
include the representation of immunizations in both CVX codes and NDC
codes as part of the ``Common Clinical Data Set'' definition for
certification to the 2015 Edition. Please see section III.B.3 ``Common
Clinical Data Set'' of this preamble for further discussion of this
associated proposal. We note that this means that a Health IT Module
certified to certification criteria that include the Common Clinical
Data Set (e.g., the ToC criterion) must demonstrate the capability to
represent immunizations in CVX codes and NDC codes. This approach
ensures that health IT would be able to support a provider's attempt to
send immunization information that includes NDC information.
---------------------------------------------------------------------------
\159\ http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=ndc. See also: http://www2a.cdc.gov/vaccines/iis/iisstandards/ndc_tableaccess.asp.
---------------------------------------------------------------------------
Immunization Information Certification Criterion
In response to the Voluntary Edition proposed rule, we received
comments recommending we discontinue the ``immunization information''
certification criterion for future editions because the necessary data
elements are enumerated in the IG for reporting to immunization
registries required for the
[[Page 16853]]
``transmission to immunization registries'' criterion. These commenters
did not see any additional value in having a standalone certification
criterion for ``immunization information'' as the value lies in being
able to transmit the immunization message. We agree with these
comments. Therefore, we are not proposing an ``immunization
information'' criterion as part of the 2015 Edition. We welcome
comments on this approach.
Transmission to Public Health Agencies--Syndromic
Surveillance
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition EHR Certification Criterion
Sec. 170.315(f)(2) (Transmission to public health agencies--syndromic
surveillance)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition certification criterion for
transmission of syndromic surveillance to public health agencies that
is revised in comparison to the 2014 Edition version (Sec.
170.314(f)(3)) for the inpatient setting. We note, however, that this
proposed certification criterion is unchanged (for the purposes of gap
certification) for the ambulatory setting. As discussed in the 2014
Edition Release 2 final rule, we understand that ambulatory providers
may be using different methods for sending syndromic surveillance
information to public health agencies, including HL7 2.5.1 and query-
based messages (79 FR 54439-54441). It is our understanding that these
methods are still being implemented and refined within the industry and
the public health community. Therefore, given the varied adoption of
methods for transmitting syndromic surveillance information to public
health agencies from ambulatory settings, we propose to continue to
distinguish between ambulatory and emergency department, urgent care,
and inpatient settings.
Emergency Department, Urgent Care, and Inpatient Settings
We propose to adopt the PHIN Messaging Guide for Syndromic
Surveillance: Emergency Department, Urgent, Ambulatory Care, and
Inpatient Settings, Release 2.0, September 2014 (``Release 2.0'').\160\
Release 2.0 provides improvements over previous versions by:
---------------------------------------------------------------------------
\160\ http://www.cdc.gov/phin/library/guides/SyndrSurvMessagGuide2_MessagingGuide_PHN.pdf
---------------------------------------------------------------------------
Re-purposing of the HL7 2.5.1 messaging structure for all
type of messages/trigger events, and combining all specifications in
one profile;
Re-structuring chapters, making them more concise and
placing supporting information into Appendixes;
Adding more implementation comments and better field name
descriptions within segment profile attributes;
Making examples better aligned to the business process;
Adding new conformance statements that simplify testing of
messages;
Making more user-friendly navigation through the document
(adding a more detailed Table of Contents, updating a format of
implementation comments, etc.);
Simplifying collection and management of data by
addressing requests for only using a text format for the ``Chief
Complaint/Reason for Visit'' Data Element; and
Correcting errors that were discovered in Version 1.9.
We believe these improvements are important to the IG and will
continue to support interoperability and data exchange of syndromic
surveillance information. As we adopted Release 1.8 of the IG in 2012
for the 2014 Edition, we believe the industry has had sufficient time
to implement Release 1.8 and could benefit from the updates in Release
2.0. Release 2.0 also updates errors and known issues from Release 1.9
that commenters noted in response to the Voluntary Edition proposed
rule as discussed in the Voluntary Edition final rule (79 FR 54440).
Given the improvements included in Release 2.0 of the IG, we propose to
adopt it at Sec. 170.205(d)(4) and include it in the 2015 Edition
``transmission to public health agencies--syndromic surveillance''
certification criterion for emergency department, urgent care, and
inpatient settings.
Ambulatory Syndromic Surveillance
We propose to permit, for ambulatory setting certification, the use
of any electronic means for sending syndromic surveillance data to
public health agencies as well as optional certification to certain
syndromic surveillance data elements. In the 2014 Edition Release 2
final rule, we adopted a certification criterion for ambulatory
syndromic surveillance at Sec. 170.314(f)(7) that permits use of any
electronic means of sending syndromic surveillance data to public
health agencies for ambulatory settings (79 FR 54440-01). We adopted
this criterion to provide EPs under the EHR Incentive Programs to meet
the Stage 2 syndromic surveillance objective with the use of CEHRT.
Because there were no IGs to support HL7 2.5.1 messaging or query-based
syndromic surveillance for ambulatory settings, we expanded our policy
to provide more flexibility to EPs to meet the syndromic surveillance
objective.
As part of the 2014 Edition criterion, we also provide the option
for technology presented for certification to demonstrate that it can
electronically produce syndromic surveillance information that contains
patient demographics, provider specialty, provider address, problem
list, vital signs, laboratory results, procedures, medications, and
insurance. Public health agencies and stakeholders that piloted query-
based models for transmitting ambulatory syndromic surveillance data
send all of these data elements. We offered this optional list of data
elements for certification to provide clarity and a path forward to
health IT developers on the data elements they should focus on for
creating syndrome-based public health transmissions in support of
query-based models, including any potential certification requirements
introduced through future rulemaking. Due to the continued lack of
mature IGs at this time, we propose to take the same approach for 2015
Edition syndromic surveillance certification for the ambulatory
setting.
Transmission to Public Health Agencies--Reportable
Laboratory Tests and Values/Results
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(f)(3) (Transmission to public health agencies--reportable
laboratory tests and values/results)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition certification criterion that is
revised in comparison to the 2014 Edition ``transmission of reportable
laboratory tests and values/results'' criterion (Sec. 170.314(f)(4)).
We have named this criterion ``transmission to public health agencies--
reportable laboratory tests and values/results'' to clearly convey the
capabilities included in this criterion as they relate to the intended
recipient of the data. We propose to include and adopt an updated IG
for laboratory reporting to public health, an updated version of SNOMED
CT[supreg], and an updated version of LOINC[supreg]. We also propose to
make a technical amendment to the regulation text for the 2014 Edition
criterion in order to have it continue to reference the appropriate
standard and implementation specifications \161\ after we restructure
[[Page 16854]]
the regulatory text hierarchy at Sec. 170.205(g) to accommodate our
2015 Edition proposal.
---------------------------------------------------------------------------
\161\ HL7 2.5.1 and HL7 Version 2.5.1: Implementation Guide:
Electronic Laboratory Reporting to Public Health, Release 1 with
Errata and Clarifications and ELR 2.5.1 Clarification Document for
EHR Technology Certification.
---------------------------------------------------------------------------
CDC worked in conjunction with the HL7 Public Health Emergency
Response Workgroup to develop an updated IG (HL7 Version 2.5.1
Implementation Guide: Electronic Laboratory Reporting to Public Health,
Release 2 (US Realm), DSTU R1.1, 2014 or ``Release 2, DSTU R1.1'') that
address technical corrections and clarifications for interoperability
with laboratory orders and other laboratory domain implementation
guides. Specifically, ``Release 2, DSTU R1.1'': \162\
---------------------------------------------------------------------------
\162\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=329.
---------------------------------------------------------------------------
Corrects errata;
Updates Objective Identifiers;
Applies conformance statements from the LRI DSTU;
Provides technical corrections; and
Updates usage for consistent treatment of modifier fields.
As we adopted Release 1 of the IG in 2012 for the 2014 Edition, we
believe the industry has had sufficient time to implement Release 1 and
could benefit from the updates in ``Release 2, DSTU R1.1.'' Given the
improvements included in the updated IG (Release 2, DSTU R1.1), we
propose to adopt it at Sec. 170.205(g)(2) and include it in the 2015
Edition ``transmission of reportable laboratory tests and values/
results'' certification criterion at Sec. 170.315(f)(3). As noted
above, to properly codify this proposal in regulation, we would have to
modify the regulatory text hierarchy in Sec. 170.205(g) to designate
the standard and implementation specifications referenced by the 2014
Edition ``transmission of reportable laboratory tests and values/
results'' certification criterion at Sec. 170.205(g)(1) instead of its
current designation at Sec. 170.205(g).
We propose to include the September 2014 Release of the U.S.
Edition of SNOMED CT[supreg] and LOINC[supreg] version 2.50 in this
criterion. We refer readers to section III.A.2.d (``Minimum Standards''
Code Sets) for further discussion of our adoption of SNOMED CT[supreg]
and LOINC[supreg] as minimum standards code sets and our proposals to
adopt the versions cited above, or potentially newer versions if
released before a subsequent final rule, as the baselines for
certification to the 2015 Edition.
Transmission to Cancer Registries
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(f)(4) (Transmission to cancer registries)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``transmission to cancer
registries'' certification criterion that is revised in comparison to
the 2014 Edition ``transmission to cancer registries'' certification
criterion (Sec. 170.314(f)(6)). We propose to adopt an HL7 version
cancer reporting IG, adopt an updated version of SNOMED CT[supreg], and
adopt an updated version of LOINC[supreg]. We also propose to make a
technical amendment to the regulation text for the 2014 Edition
certification criterion so that it continues to reference the
appropriate standard \163\ in the regulatory text hierarchy at Sec.
170.205(i), while accommodating our 2015 Edition proposal.
Specifically, we propose to modify the 2014 Edition certification
criterion to reference Sec. 170.205(i)(1) to establish the regulatory
text hierarchy necessary to accommodate the standard and IG referenced
by the proposed 2015 Edition certification criterion.
---------------------------------------------------------------------------
\163\ Standard. HL7 Clinical Document Architecture (CDA),
Release 2.0, Normative Edition (incorporated by reference in Sec.
170.299). Implementation specifications. Implementation Guide for
Ambulatory Healthcare Provider Reporting to Central Cancer
Registries, HL7 Clinical Document Architecture (CDA), Release 1.0
(incorporated by reference in Sec. 170.299).
---------------------------------------------------------------------------
The 2014 Edition ``transmission to cancer registries'' criterion at
Sec. 170.314(f)(6) references the following IG for cancer reporting:
Implementation Guide for Ambulatory Healthcare Provider Reporting to
Central Cancer Registries, HL7 Clinical Document Architecture (CDA),
Release 1.0. Since the publication of the 2014 Edition Final Rule, CDC
worked with HL7 to introduce the IG to the standards developing
organization processes. In doing so, an updated IG has been developed
to address technical corrections and clarifications for
interoperability with EHRs and cancer registries (HL7 Implementation
Guide for CDA(copyright) Release 2: Reporting to Public Health Cancer
Registries from Ambulatory Healthcare Providers Release 1 or ``HL7 IG
Release 1''). Specifically, HL7 IG Release 1: \164\
---------------------------------------------------------------------------
\164\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=383.
---------------------------------------------------------------------------
Aligns with C-CDA Release 2.0 templates, where possible;
Adds new data elements, including grade, pathologic TNM
stage,\165\ family history of illness, height and weight, discrete
radiation oncology items, planned medications, and planned procedures;
---------------------------------------------------------------------------
\165\ The TNM Classification of Malignant Tumours (TNM) is a
cancer staging system that describes the extent of a person's
cancer.
---------------------------------------------------------------------------
Changes optionality for some data elements in response to
cancer community input and to align with C-CDA Release 2.0 templates;
Improves documentation and aligns conformance statements
with table constraints;
Adds some new vocabulary links and a new reportability
list for ICD-10-CM;
Fixes some within-document references;
Fixes some LOINC[supreg] codes;
Fixes some Code System and Value Set Object Identifiers;
Fixes some conformance verbs;
Improves sample XML snippets;
Fixes some conformance verbs and data element names in
Appendix B ``Ambulatory Healthcare Provider Cancer Event Report--Data
Elements''; and
Fixes a value in the value set.
These improvements will continue to promote interoperability
between health IT and cancer registries for improved cancer case
reporting to public health agencies. As we adopted the non-HL7 Release
1 of the IG in 2012 for the 2014 Edition, we believe the industry has
had sufficient time to implement that IG and could benefit from the
updates in HL7 IG Release 1. Therefore, given the improvements that
will be included in HL7 IG Release 1 as described above, we propose to
adopt it at Sec. 170.205(i)(2) and include it in the proposed 2015
Edition ``transmission to cancer registries'' certification criterion.
We propose to include the September 2014 Release of the U.S.
Edition of SNOMED CT[supreg] and LOINC[supreg] version 2.50 in this
criterion. We refer readers to section III.A.2.d (``Minimum Standards''
Code Sets) for further discussion of our adoption of SNOMED CT[supreg]
and LOINC[supreg] as minimum standards code sets and our proposals to
adopt the versions cited above, or potentially newer versions if
released before a subsequent final rule, as the baselines for
certification to the 2015 Edition.
Cancer Case Information
In response to the Voluntary Edition proposed rule, we received
comments recommending we discontinue proposing and adopting a ``cancer
case information'' certification criterion for future editions because
the necessary data elements are enumerated in the IG for reporting to
cancer registries that we include in editions of ``transmission to
cancer registries'' criteria. We agree with this assessment. Therefore,
we are not proposing a 2015 Edition ``cancer case information''
certification criterion
[[Page 16855]]
similar to the one we adopted for the 2014 Edition. We welcome comments
on this approach.
Transmission to Public Health Agencies--Case Reporting
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(f)(5) (Transmission to public health agencies--case
reporting)
------------------------------------------------------------------------
We propose to adopt a new certification criterion in the 2015
Edition for electronic transmission of case reporting information to
public health agencies.
Health IT standards continue to evolve to address new and emerging
use cases for health care. The utility of health IT for supplemental
purposes has been limited due to a lack of uniformity in the
terminology and definitions of data elements across health IT systems.
This limitation is compounded by the fact that provider workflow often
records patient information in unstructured free-text well after
episodes of care. Linking data in EHR systems with other data in a
uniform and structured way could accelerate quality and safety
improvement, population health, and research.
Toward this end, the S&I Structured Data Capture \166\ (SDC)
initiative is a multi-stakeholder group working on standards-based
architecture so that a set of structured data can be accessed from
health IT and stored for merger with comparable data for other relevant
purposes. The SDC initiative is developing a set of standards that will
enable health IT to capture and store structured data. These standards
will build upon and incorporate existing standards, including the IHE
Retrieve Form for Data Capture (RFD) profile. As part of this work, the
SDC initiative has developed a surveillance case report form for public
health reporting of notifiable diseases as part of the IHE Quality,
Research, and Public Health Technical Framework Supplement, Structured
Data Capture, Trial Implementation (September 5, 2014) standard.\167\
The case report form can be further specified and used to
electronically report vital statistics, vaccine adverse event
reporting, school/camp/daycare physical, early hearing detection and
intervention/newborn hearing screening, and cancer registry reporting,
among other public health reporting data.
---------------------------------------------------------------------------
\166\ http://wiki.siframework.org/Structured+Data+Capture+Initiative.
\167\ http://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_SDC.pdf.
---------------------------------------------------------------------------
We believe that case reporting from health care providers to public
health agencies could be more real-time, structured, and efficient
through the use of the standard case report form that the SDC
initiative has developed. Therefore, we propose to adopt a
certification criterion for electronic transmission of case reporting
information to public health that would require a Health IT Module to
be able to electronically create case reporting information for
electronic transmission in accordance with the IHE Quality, Research,
and Public Health Technical Framework Supplement, Structured Data
Capture, Trial Implementation (September 5, 2014) standard, which we
propose to adopt at Sec. 170.205(q)(1). As mentioned above, this
standard and our proposal include compliance with other existing
standards. One such standard is the CDA Release 2.0, which is a
foundational standard for use in sending and receiving case reporting
information.
To note, for testing to this criterion, a Health IT Module would
need to demonstrate that it can create and send a constrained
transition of care document to a public health agency, accept a URL in
return, be able to direct end users to the URL, and adhere to the
security requirements for the transmission of this information.
We recognize that the Fast Health Interoperability Resource
(FHIR[supreg]) REST API and FHIR-based standard specifications will
likely play a role in an interoperable health IT architecture. FHIR
resources that implement SDC concepts and support the use of case
reporting to public health would likely play a role in that scenario.
The current HL7 FHIR Implementation Guide: Structure Data Capture
(SDC), Release 1 \168\ is a ``draft for comment'' with a DSTU ballot
planned for mid-2015. Given this trajectory, we solicit comment on
whether we should consider adopting the HL7 FHIR Implementation Guide:
SDC DSTU that will be balloted in mid-2015 in place of, or together
with, the IHE Quality, Research, and Public Health Technical Framework
Supplement. We are aware of a proposed HL7 working group known as the
Healthcare Standards Integration Workgroup that will collaborate on
FHIR resources considered co-owned with the IHE-HL7 Joint Workgroup
\169\ within IHE. The implementation guides created from the S&I SDC
Initiative is part of this joint workgroup's area of responsibility.
Therefore, we intend to work with these coordinated efforts to ensure a
complementary and coordinated approach for case reporting using SDC.
---------------------------------------------------------------------------
\168\ http://hl7.org/implement/standards/FHIR-Develop/sdc.html.
\169\ http://wiki.ihe.net/index.php?title=IHE-HL7_Joint_Workgroup.
---------------------------------------------------------------------------
Transmission to Public Health Agencies--Antimicrobial Use
and Resistance Reporting
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(f)(6) (Transmission to public health agencies--
antimicrobial use and resistance reporting)
------------------------------------------------------------------------
We propose to adopt a new 2015 Edition certification criterion for
transmission of antimicrobial use and resistance data to public health
agencies that would require a Health IT Module to be able to
electronically create antimicrobial use and resistance reporting
information for electronic transmission in accordance with specific
sections of the HL7 Implementation Guide for CDA [supreg] Release 2--
Level 3: Healthcare Associated Infection Reports, Release 1, U.S. Realm
(August 2013).
Collection and analysis of data on antimicrobial use and
antimicrobial resistance are important components of antimicrobial
stewardship programs throughout the nation and efforts by health care
organizations and public health agencies aimed at detecting,
preventing, and responding to resistant pathogens. Surveillance
provides vital data for use by health care facilities, local, state,
and federal agencies, research and development teams, policymakers, and
the public. Electronic submission of antimicrobial use and
antimicrobial resistance data to a public health registry can promote
timely, accurate, and complete reporting, particularly if data is
extracted from health IT systems and delivered using well established
data exchange standards to a public health registry. The HL7
Implementation Guide for CDA [supreg] Release 2--Level 3: Healthcare
Associated Infection Reports, Release 1--US Realm--August 2013 \170\
(``HAI IG'') is an ANSI-approved standard for electronic reporting of
antimicrobial use and antimicrobial resistance data to the CDC's
National Healthcare Safety Network (NHSN), the largest health care-
associated infection (HAI) reporting system in the United States with
over 9,000 health care facilities participating. The HAI IG provides
details for reporting from EPs, eligible hospitals, and CAHs.
---------------------------------------------------------------------------
\170\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=20.
---------------------------------------------------------------------------
We propose to test and certify a Health IT Module for conformance
with the following sections of the IG:
[[Page 16856]]
HAI Antimicrobial Use and Resistance (AUR) Antimicrobial
Resistance Option (ARO) Report (Numerator) specific document template
in Section 2.1.2.1 (pages 69-72);
Antimicrobial Resistance Option (ARO) Summary Report
(Denominator) specific document template in Section 2.1.1.1 (pages 54-
56); and
Antimicrobial Use (AUP) Summary Report (Numerator and
Denominator) specific document template in Section 2.1.1.2 (pages 56-
58).
We propose to adopt these specific sections of the IG in Sec.
170.205(r)(1). Note that the specific document templates referenced
above include conformance to named constraints in other parts of the
IG, and we would expect a Health IT Module presented for certification
to this criterion to conform to all named constraints within the
specified document template.
Transmission to Public Health Agencies--Health Care
Surveys
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(f)(7) (Transmission to public health agencies--health
care surveys)
------------------------------------------------------------------------
We propose to adopt a new 2015 Edition certification criterion for
transmission of health care surveys to public health agencies. We
propose to adopt a certification criterion for transmission of health
care survey information to public health agencies that would require a
Health IT Module to be able to create health care survey information
for electronic transmission in accordance with the HL7 Implementation
Guide for CDA [supreg] Release 2: National Health Care Surveys (NHCS),
Release 1--US Realm, Draft Standard for Trial Use (December 2014),\171\
which we propose to adopt at Sec. 170.205(s)(1).
---------------------------------------------------------------------------
\171\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=385.
---------------------------------------------------------------------------
The National Ambulatory Medical Care Survey (NAMCS) is a national
survey designed to meet the need for objective, reliable information
about the provision and use of ambulatory medical care services in the
U.S. Findings are based on a sample of visits to non-federal employed
office-based physicians who are primarily engaged in direct patient
care.
The National Hospital Ambulatory Medical Care Survey (NHAMCS) is
designed to collect data on the utilization and provision of ambulatory
care services in hospital emergency and outpatient departments.
Findings are based on a national sample of visits to the emergency
departments and outpatient departments of general and short-stay
hospitals.
The kinds of data contained in this survey are:
Patient demographics such as date of birth, sex, race and
ethnicity;
Vital signs such as height, weight and blood pressure;
Reason for visit or chief complaint;
Diagnoses associated with the visit;
Chronic conditions that the patient has at the time of the
visit;
Procedures provided or ordered;
Diagnostic tests ordered or provided;
New or continued medications at the time of the visit; and
Other variables such as tobacco use, whether the provider
is the patient's primary care provider, how many times has the patient
been seen in the practice in the past 12 months, which type of
providers were seen at the visit, amount of time spent with the
provider, and visit disposition.
Automating the survey process using the CDA standard streamlines
the collection of data and increases the sample pool by allowing all
providers who want to participate in the surveys to do so. The HL7
Implementation Guide for CDA [supreg] Release 2: National Health Care
Surveys (NHCS), Release 1--US Realm, Draft Standard for Trial Use
(December 2014) defines the electronic submission of the data to the
CDC. We clarify that the IG is intended for the transmission of survey
data for both the NAMCS (e.g., for ambulatory medical care settings)
and NHAMCS (e.g., for hospital ambulatory settings including emergency
departments and outpatient departments). Templates included in this IG
align with the C-CDA standard. Additionally, the templates in this IG
expand on the scope of the original NAMCS and NHAMCS survey data
elements and do not constrain the data collected to the narrow lists on
the survey instruments; rather they allow any service, procedure or
diagnosis that has been recorded.
Automated Numerator Recording
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(g)(1) (Automated numerator recording)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``automated numerator
recording'' certification criterion that is unchanged in comparison to
the 2014 Edition ``automated numerator recording'' criterion. We note,
however, that the test procedure for this criterion would be different
from the 2014 Edition ``automated numerator recording'' certification
criterion in order to remain consistent with the applicable objectives
and measures required under the EHR Incentive Programs.
Automated Measure Calculation
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(g)(2) (Automated measure calculation)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``automated measure
calculation'' certification criterion that is unchanged in comparison
to the 2014 Edition ``automated measure calculation'' criterion. We
propose to apply the guidance provided for the 2014 Edition ``automated
measure calculation'' certification criterion in the 2014 Edition final
rule in that a Health IT Module must be able to support all CMS-
acceptable approaches for measuring a numerator and denominator in
order for the Health IT Module to meet the proposed 2015 Edition
``automated measure calculation'' certification criterion.\172\ We also
propose that the interpretation of the 2014 Edition ``automated measure
calculation'' certification criterion in FAQ 32 \173\ would apply to
the proposed 2015 Edition ``automated measure calculation''
certification criterion.
---------------------------------------------------------------------------
\172\ 77 FR 54244-54245.
\173\ http://www.healthit.gov/policy-researchers-implementers/32-question-11-12-032.
---------------------------------------------------------------------------
We note that the test procedure for this criterion would be
different from the 2014 Edition ``automated measure calculation''
certification criterion in order to remain consistent with the
applicable objectives and measures required under the EHR Incentive
Programs.
Safety-Enhanced Design
------------------------------------------------------------------------
-------------------------------------------------------------------------
2015 Edition Health IT Certification Criterion
Sec. 170.315(g)(3) (Safety-enhanced design)
------------------------------------------------------------------------
We propose to adopt a 2015 Edition ``safety-enhanced design'' (SED)
certification criterion that is revised in comparison to the 2014
Edition ``safety-enhanced design'' criterion. We propose to add
certification criteria to this criterion that we believe include
capabilities that pose a risk for patient harm and, therefore, an
opportunity for error prevention. We propose to provide further
compliance clarity for the data elements described in NISTIR 7742 \174\
that are required to be submitted as part of the summative usability
test results and to specifically include these data
[[Page 16857]]
elements as part of the certification criterion.
---------------------------------------------------------------------------
\174\ http://www.nist.gov/manuscript-publication-search.cfm?pub_id=907312. NISTIT 7742 is a valid and reliable
publication for user-centered design processes.
---------------------------------------------------------------------------
Certification Criteria Identified in the SED Criterion for UCD
Processes
We propose to include seventeen (17) certification criteria (seven
are new) in the 2015 Edition SED certification criterion, as listed
below (emphasis added for new criteria). For each of the referenced
certification criteria and their corresponding capabilities presented
for certification, user-centered design (UCD) processes must have been
applied in order satisfy this certification criterion.
Sec. 170.315(a)(1) Computerized provider order entry--
medications
Sec. 170.315(a)(2) Computerized provider order entry--
laboratory
Sec. 170.315(a)(3) Computerized provider order entry--
diagnostic imaging
Sec. 170.315(a)(4) Drug-drug, drug-allergy interaction
checks
Sec. 170.315(a)(5) Demographics
Sec. 170.315(a)(6) Vital signs, BMI, and growth charts
Sec. 170.315(a)(7) Problem list
Sec. 170.315(a)(8) Medication list
Sec. 170.315(a)(9) Medication allergy list
Sec. 170.315(a)(10) Clinical decision support
Sec. 170.315(a)(18) Electronic medication administration
record
Sec. 170.315(a)(20) Implantable device list
Sec. 170.315(a)(22) Decision support--knowledge artifact
Sec. 170.315(a)(23) Decision support--service
Sec. 170.315(b)(2) Clinical information reconciliation
and incorporation
Sec. 170.315(b)(3) Electronic prescribing
Sec. 170.315(b)(4) Incorporate laboratory tests/results
The continued submission of summative usability test results
promotes transparency and can foster health IT developer competition,
spur innovation, and enhance patient safety. With this in mind, we also
seek comment on whether there are other certification criteria that we
omitted from this proposed SED criterion that commenters believe should
be included.
NISTIR 7742 Submission Requirements
In the 2014 Edition final rule, we specified that the information
listed below from the NISTIR 7742 ``Customized Common Industry Format
Template for Electronic Health Record Usability Testing'' (NIST 7742)
\175\ was required to be submitted for each and every one of the
criteria specified in the 2014 Edition SED criterion (77 FR 54188). For
the 2015 Edition SED criterion, we propose to include the information
below in the regulation text of the 2015 Edition SED criterion to
provide more clarity and specificity for the information requested to
be provided to demonstrate compliance with this certification
criterion. The findings that would be required to be submitted for each
and every one of the criteria specified in the 2015 Edition SED
criterion (and become part of the test results publicly available on
the Certified Health IT Product List (CHPL)) are:
---------------------------------------------------------------------------
\175\ http://www.nist.gov/manuscript-publication-search.cfm?pub_id=907312.
---------------------------------------------------------------------------
Name and version of the product