Data Element
Pack-years
Description

The patient’s pack-years of smoking, or the information needed to determine the pack-years (e.g., packs per day and years of smoking).
Submitted By: Kensaku Kawamoto, MD, PhD, MHS / University of Utah
Data Element Information
Rationale for Separate Consideration Because this information is needed to assess a patient’s health risks from smoking and whether a patient should receive potentially life-saving clinical interventions such as lung cancer screening. Lung cancer screening could save more lives than breast cancer screening (over 10,000 Americans per year) but is currently provided to only about 10% of eligible Americans.
Use Case Description(s)
Use Case Description To determine whether patients should be screened for lung cancer with low-dose computed tomography (LDCT). Appropriate LDCT screening could save more lives than breast cancer screening (>10,000 Americans a year), and this information is required for determining whether a patient should be screened. A free SMART on FHIR app is available for assessing patient risk and supporting the shared decision making required by payors. A non-SMART on FHIR version of this app is available at https://screenlc.com/.
Estimate the breadth of applicability of the use case(s) for this data element This type of smoking data are captured in structured form routinely in clinical practice and in EHR systems. This is expected to affect the more than 34 million U.S. adults who currently smoke cigarettes, as well as past smokers.
Link to use case project page https://digital.ahrq.gov/ahrq-funded-projects/scalable-decision-support-and-shared-decisionmaking-lung-cancer-screening
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Reducing the cost of care
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) Unified Code for Untis of Measure (UCUM) units for pack years and packs per day. There is also a LOINC code for packs per day (8663-7) and years smoked (88029-4).
https://www.hl7.org/fhir/valueset-ucum-common.html, https://loinc.org/8663-7/, https://loinc.org/88029-4/
Additional Specifications N/A
Current Use In limited use in production environments
Supporting Artifacts Through funding from multiple organizations include the Veterans Administration, the University of Utah, and the Agency for Healthcare Research and Quality (see link below), a free SMART on FHIR app for lung cancer screening shared decision making has been developed and is now in clinical use at University of Utah Health. This also involved extending the US Core Smoking Status Profile to include the needed data elements in the Epic FHIR API. In partnership with Epic, we are working to widely disseminate both the enhanced FHIR API and the SMART on FHIR app. We are also actively working on integration with other EHR platforms.
https://digital.ahrq.gov/ahrq-funded-projects/scalable-decision-support-and-shared-decisionmaking-lung-cancer-screening
Extent of exchange 1
Supporting Artifacts This data element can be exchange across institutions, but a primary use case is expected to be use within an institution by standards-based tools such as SMART on FHIR apps and CDS Hooks services.
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) No relevant restrictions are anticipated.
Restrictions on Use (e.g. licensing, user fees) No relevant restrictions are anticipated.
Privacy and Security Concerns No relevant concerns are anticipated.
Estimate of Overall Burden Because the data are already routinely captured in structured form in many EHRs, and it would be fine for this information to only be made available if already captured in structured form, there should be minimal burden compared to the current state with regard to 1) supporting the data elements in the EHR and 2) users collecting the information.
With regard to adding this information to the current USCDI smoking information, the effort is expected to be limited as the data elements are already widely captured in structured form in EHRs today. For example, it took our group less than 1 week to implement support for these data elements within the Epic FHIR API.
Other Implementation Challenges Different EHRs may capture the relevant information differently. E.g., one may record start dates and quit dates, with years of smoking calculated as needed, while another may capture years of smoking directly. Such differences would need to be resolved, e.g., by standardizing on a common representation when the data is shared (e.g., years of smoking).

Comment

Log in or register to post comments