Department of health and human services

5. Pharmacogenomics Data – Request for Comment

Pharmacogenomics data identifies genetic variants in individuals that alter their metabolism or other interactions with medications and can lead to serious adverse events. This information is being included in an increasing number of FDA-approved drug labels. Health IT systems that can capture pharmacogenomics information could be used to increase patient safety and enhance patient outcomes.

To our knowledge, in general, health IT has not yet captured genomic and genetic patient information – the presence of clinically significant genomic variants – in a structured manner such as exists for other categorical clinical findings or laboratory-derived data.²¹⁴ This information may currently be captured in free text and static PDFs except in a few individual health centers where custom health IT solutions have been developed. However, work on standards and other precursors required for wider adoption is underway, including through the Institute of Medicine, HL7, and LOINC^®.²¹⁵ Many of these efforts are using pharmacogenomic variations as prototypes because the clinical utility of a subset of such variants has a greater evidence-base, has wide clinical applicability, and is already in clinical use. Pharmacogenomic implementation aims to limit preventable adverse effects and maximize efficacy by using information about genomic variants to enable optimal drug choices and patient-specific dosing.

For the use case of CDS informed by pharmacogenetic information, considerable ambiguity exists with respect to the incorporation of CDS systems that facilitate providers taking advantage of pharmacogenomic information.²¹⁶ Thus, there is an opportunity for further specification of standards and implementation of pharmacogenomic data for CDS within health IT systems. We also believe there may be opportunities for capturing genomic patient data in laboratory results, for drug-genome interactions, and for genomic metabolizer status (defined risks to certain medications) in a structured way within health IT.

Note that we have previously adopted a 2014 Edition “family health history” certification criterion that referenced the HL7 standard for representing genomic information and are proposing a 2015 Edition “family health history – pedigree” certification criterion that references that same standard as well as a related IG. In addition to their relevance for the tested patient, genomic test results are unique in that they have the potential to inform the health care of blood relatives of the tested individual, similar to a shared family history. We note that any application of genomic information across family members must be done in accordance with the HIPAA Privacy Rule and other privacy and patient rights laws regarding genetic information at the federal and state levels.

We acknowledge that individually identifiable genetic information may be subject to federal and state privacy laws and regulations that are more privacy restrictive than the HIPAA Privacy Rule. As such, these privacy issues will impact any certification criteria or policy we might propose to adopt in future rulemaking. We therefore welcome input on factors to consider for health IT that allows the user to use or disclose genetic information in a manner compliant with federal and state privacy laws. Note that we are proposing two new 2015 Edition certification criteria for “data segmentation for privacy – send” and “data segmentation for privacy – receive” that would focus on the capability to separately track (“segment”) individually identifiable health information that is protected by rules that are more restrictive than the HIPAA Privacy Rule (please refer to Section III.A.3 for more information). We believe that the capabilities offered by the proposed “data segmentation for privacy” criteria could be leveraged for the segmentation of individually identifiable genetic information that are protected by federal and state privacy laws and regulations.

We also acknowledge that the inclusion of genomic information in health IT-related mechanisms will need to be carefully implemented to balance the benefit to patients while avoiding discrimination against persons with or at risk for the development of future health issues, and their family members.

In collaboration with the National Institutes of Health, we solicit comment on whether:

• 
  The 2015 Edition “medication allergy list” certification criterion should include the capability to integrate genotype-based drug metabolizer rate information.
  
• 
  The 2015 Edition “drug-drug, drug-allergy interactions checks for CPOE” certification criterion or as a separate certification criterion should include pharmacogenomic CDS for “drug-genome interactions.”
  
• 
  We should offer 2015 Edition certification for CDS that incorporate a patient’s pharmacogenomic genotype data into the CPOE prescribing process with the goal of avoiding adverse prescribing outcomes for known drug-genotype interactions.
  
• 
  There are certification approaches that could enhance the end-user’s (provider’s) adoption and continued use of health IT implementations that guide prescribing through CDS using pharmacogenomic data.
  
• 
  There are existing or developing standards applicable to the capture, storage, display, and exchange of potentially clinically relevant genomic data, including the pharmacogenomic subset.
  
• 
  We should offer certification for health IT functionality that could facilitate HIPAA-compliant sharing of discrete elements of a patient’s genomic information from their record to the family history section of a relative’s record.
  
• 
  The proposed “data segmentation for privacy” criteria would provide needed health IT functions with respect to the storage, use, transmission, and disclosure of genetic, genomic, and pharmacogenomics information that is subject to protections under HIPAA and additional state and federal privacy and protection laws such as the Genetic Information Nondiscrimination Act (GINA).²¹⁷
  
• 
  The proposed “data segmentation for privacy” criteria adequately balance complex genetic privacy issues, such as those related to behavioral health, with the clinical value of context-appropriate availability of a patient’s actionable genetic and genomic information.
  
• 
  Health IT should be required to apply different rules for the use and exchange of genetic, genome, and pharmacogenomics data based on different groupings of diseases or conditions based on the sensitivity of the information, such as those related to behavioral health.
  
• 
  There are other factors we should consider for health IT that allows the user to use or disclose genetic information in a manner compliant with federal and state privacy laws.
  

B. Definitions

1. 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 § 170.102 and rename the current Base EHR definition at § 170.102 as the 2014 Edition Base EHR definition. To effectively rename the current Base EHR definition as the “2014 Edition Base EHR” definition, the Base EHR definition must be removed from the CFR and a “2014 Edition Base EHR” definition must be added. This is a procedural requirement and we affirm that the definition itself is not changing. However, 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 this preamble. Our new privacy and security approach would eliminate EPs’, eligible hospitals’, and 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 capabilities to record and export CQM data (§ 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) earlier in this 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” certification criterion as patient demographic and clinical health information data consistent with statutory requirements.²¹⁸ Smoking and the use of tobacco in general is the number one cause of preventable death and disease in the United States. By including this capability and criterion in the definition, it ensures that providers participating in the EHR Incentive Programs have the basic capability to capture the smoking status of patients, which permits more providers to take part in addressing (through intervention and cessation efforts) this cause of preventable disease and death.
  
• 
  It includes the 2015 Edition “implantable device list” certification as patient demographic and clinical health information data consistent with statutory requirements.²¹⁹ The ability to record and access a patient’s unique device identifiers can improve patient safety. Please see the discussion under the “implantable device list” certification criterion for further benefits derived from providers having access unique device identifier(s) for a patient’s implantable device(s).
  
• 
  It includes the 2015 Edition “application access to Common Clinical Data Set” certification criterion as a capability to both capture and query information relevant to health care quality and exchange electronic health information with, and integrate such information from other sources.²²⁰ Due to the proposed inclusion of the 2015 Base EHR definition in the proposed CEHRT definition (see “CEHRT definition” section below and in the EHR Incentive Programs Stage 3 proposed rule published elsewhere in this issue of the Federal Register), like all capabilities and criteria included in the 2015 Edition Base EHR definition, this would ensure that all EPs, eligible hospitals, and CAHs would need to adopt a Health IT Module certified to this criterion in order to have the necessary health IT to meet the CEHRT definition. As such, the inclusion of the 2015 Edition “application access to Common Clinical Data Set” certification criterion in the 2015 Edition Base EHR definition could further facilitate health information exchange by being specifically used to meet meaningful use objectives and measures as well as through it simply being readily available for use by these providers and their patients.
  
• 
  It includes the proposed 2015 Edition Health IT certification criteria that correspond to the remaining 2014 Edition certification criteria referenced in the “2014 Edition” Base EHR definition (i.e., CPOE, demographics, problem list, medication list, medication allergy list, 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 (§ 170.315(h)(1)) as well as the “Direct Project, Edge Protocol and XDR/XDM” criterion (§ 170.315(h)(2)) as equivalent alternative means for meeting the 2015 Edition Base EHR definition for the reasons discussed earlier in this preamble under the “Transport Methods and Other Protocols” section.
  

Table 5. Certification Criteria Required to Satisfy the 2015 Edition Base EHR Definition
Base EHR Capabilities	Certification Criteria
Includes patient demographic and clinical health information, such as medical history and problem lists	Demographics § 170.315(a)(5) Problem List § 170.315(a)(7) Medication List § 170.315(a)(8) Medication Allergy List § 170.315(a)(9) Smoking Status § 170.315(a)(12) Implantable Device List § 170.315(a)(20)
Capacity to provide clinical decision support	Clinical Decision Support § 170.315(a)(10)
Capacity to support physician order entry	Computerized Provider Order Entry § 170.315(a)(1), (2) or (3)
Capacity to capture and query information relevant to health care quality	Clinical Quality Measures § 170.315(c)(1)
Capacity to exchange electronic health information with, and integrate such information from other sources	Transitions of Care § 170.315(b)(1) Data Portability § 170.315(b)(6) Application Access to Common Clinical Data Set § 170.315(g)(7) Direct Project § 170.315(h)(1) or Direct Project, Edge Protocol, and XDR/XDM § 170.315(h)(2)