Information related to interactions between healthcare providers and a patient.

Data Element

Information from the submission form
Encounter Identifier
Description
Sequence of characters by which an encounter is known.
Submitted By: Maria Michaels / CDC
Data Element Information
Use Case Description(s)
Use Case Description Actively monitoring diseases, making decisions about public health threats, identifying trends in healthcare services utilization and other public health matters depend on accessible and accurate data. EHRs are a data source that can provide timely and relevant data beyond its use by health care providers. EHR data, if made more available for public health professionals and researchers, can lead to more rapid disease detection, tracking, and treatment and innovation in healthcare delivery.

A patient's encounter with a provider of medical services, ranging from an ambulatory office visit with the patient's primary care provider, to a sudden, acute injury necessitating a trip to an Emergency Department to an admission to and subsequent discharge from a hospital for surgery is a fundamental organizing principle across the healthcare industry. The encounter class of data elements is widely used in EHRs and other systems for clinical care, payment purposes and operational efficiency. Beginning with the encounter status, often used as a trigger for clinical workflow, through classifying, numerically identifying and assigning a date and time to the encounter, to identifying the patient and provider subjects of the encounter as well as their roles form the structure of the encounter these encounter elements have varied clinical and administrative uses. The chief complaint, reason for visit and encounter diagnoses capture the richness of the encounter while the expected source of encounter payment and encounter discharge disposition provide information for follow up and payment. The majority of the candidate encounter data elements here are either mandatory or must support data elements of the US CORE Encounter Profile or Shall or Should data elements in many CDA use cases.

The Making EHR Data More Available for Research and Public Health (MedMorph) project's goal is to create a reliable, scalable, and interoperable method to get electronic health record data for multiple public health and research scenarios (use cases). MedMorph has identified Cancer Registry Reporting, Healthcare Surveys, Electronic Initial Case Reporting (eCR), Hepatitis C Reporting, Birth Reporting and Research (PCORNet) use cases that support the adoption of these encounter data elements. These specific use cases are described in more depth on their respective web pages.
Estimated number of stakeholders capturing, accessing using or exchanging All 50 states participate in one or more of the MedMorph public health and research use cases that exchange these encounter data elements. Up to 14 territorial or city jurisdictions also participate in one of these public health use cases and use these data elements.

All hospitals and physicians who diagnose or treat cancer are required to provide encounter information to state cancer registries.

Approximately 620,000 physicians in the US are active and have at least some component of ambulatory practice and thus are annually eligible to sampling and recruitment into the National Ambulatory Medical Care Survey (NAMCS), which samples from between 3,500 to 20,000 of these physicians annually. Presently each sampled physician submits one weeks' worth of patient encounters to NAMCS. Approximately 600 hospitals are in the National Hospital Care Survey (NHCS). 1/3 of that number are either in, or actively being recruited into, the EHR data submission mode for NHCS. NHCS is already receiving electronic CDA documents. When they reach their target of 200 hospitals submitting by this mode annually they will be receiving >1.2 million documents and sets including multiple sets of medication data annually. 

Related to birth reporting, every year there are approximately 3.7 million births in the United States. Consumption of this data is widespread. Every jurisdiction in the country captures birth certification information and immunization administration. Most also capture birth defects and fetal deaths. Healthcare systems that provide care for expectant mothers should be collecting this data.

There were approximately 1,000,000 practicing physicians (as of 2020), approximately 120,000 certified physician assistants (as of 2019) and 290,000 licensed nurse practitioners (as of 2019). Most of these licensed clinicians interact with one of these public health use cases intermittently, annually. As of 2018 AHA reported 6,146 hospitals in the US experiencing 36,353,946 admissions. Almost all of those hospitals and many of the admissions interact with one or more of the public health and or research use cases. The vast majority of these exchanges include most or at least some of the encounter data elements contained in this submission.

Supporting Links:
MedMorph: https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html

Cancer Reporting: https://www.cdc.gov/cancer/npcr/

Hepatitis C Reporting: https://www.cdc.gov/hepatitis/pdfs/HepatitisCaseRprtForm.pdf

Health Care Surveys: https://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm

eCR: https://www.cdc.gov/ecr/index.html

PCORnet: https://pcornet.org/

Birth Reporting: https://www.cdc.gov/nchs/nvss/births.htm
Link to use case project page https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html Cancer Reporting: https://www.cdc.gov/cancer/npcr/ Hepatitis C Reporting: https://www.cdc.gov/hepatitis/pdfs/HepatitisCaseRprtForm.pdf Health Care Surveys: https://www.cdc.gov
Supporting Attachments MedMorph-HealthCareSurveyReportingUseCase-DRAFT.pdf
MedMorph-CancerReportingUseCase-DRAFT.pdf
MedMorph-ChronicHepatitisCSurveillanceUseCase-DRAFT.pdf
Use Case Description A foundational goal of MedMorph is generalizability beyond the 10 use cases that are actively informing the MedMorph project, in order to support many more public health and research use cases. Therefore, other public health and research use cases that use the MedMorph architecture will also benefit from the adoption of these encounter data elements.
Estimated number of stakeholders capturing, accessing using or exchanging All 50 states participate in one or more of the MedMorph public health and research use cases that exchange these encounter data elements. Up to 14 territorial or city jurisdictions also participate in one of these public health use cases and use these data elements.

All hospitals and physicians who diagnose or treat cancer are required to provide encounter information to state cancer registries.

Approximately 620,000 physicians in the US are active and have at least some component of ambulatory practice and thus are annually eligible to sampling and recruitment into the National Ambulatory Medical Care Survey (NAMCS), which samples from between 3,500 to 20,000 of these physicians annually. Presently each sampled physician submits one weeks' worth of patient encounters to NAMCS. Approximately 600 hospitals are in the National Hospital Care Survey (NHCS). 1/3 of that number are either in, or actively being recruited into, the EHR data submission mode for NHCS. NHCS is already receiving electronic CDA documents. When they reach their target of 200 hospitals submitting by this mode annually they will be receiving >1.2 million documents and sets including multiple sets of medication data annually. 

Related to birth reporting, every year there are approximately 3.7 million births in the United States. Consumption of this data is widespread. Every jurisdiction in the country captures birth certification information and immunization administration. Most also capture birth defects and fetal deaths. Healthcare systems that provide care for expectant mothers should be collecting this data.

There were approximately 1,000,000 practicing physicians (as of 2020), approximately 120,000 certified physician assistants (as of 2019), and 290,000 licensed nurse practitioners (as of 2019). Most of these licensed clinicians interact with one of these public health use cases intermittently, annually. As of 2018, AHA reported 6,146 hospitals in the US experiencing 36,353,946 admissions. Almost all of those hospitals and many of the admissions interact with one or more of the public health and or research use cases. The vast majority of these exchanges include most or at least some of the encounter data elements contained in this submission.
Healthcare Aims
  • Improving the health of populations
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) Encounter Status: FHIR Encounter Status: http://hl7.org/fhir/ValueSet/encounter-status

Classification of Encounter: V3 Value SetActEncounterCode: http://hl7.org/fhir/ValueSet/v3-ActEncounterCode

Encounter Type: FHIR Encounter type: http://www.ama-assn.org/go/cpt

Encounter participant type: FHIR Participant type: http://hl7.org/fhir/ValueSet/encounter-participant-type

Reason for the encounter: FHIR Encounter Reason Codes: http://hl7.org/fhir/ValueSet/encounter-reason

Hospital encounter discharge disposition: FHIR Discharge disposition: http://hl7.org/fhir/ValueSet/encounter-discharge-disposition

Expected source(s) of payment for this encounter: FHIR Coverage Type and Self-Pay Codes: http://hl7.org/fhir/R4/valueset-coverage-type.html

Encounter chief complaint: FHIR DiagnosisRole: http://hl7.org/fhir/R4/valueset-diagnosis-role.html
http://hl7.org/fhir/ValueSet/encounter-status Classification of Encounter:http://hl7.org/fhir/ValueSet/v3-ActEncounterCode Encounter Type: http://www.ama-assn.org/go/cpt Encounter participant type: http://hl7.org/fhir/ValueSet/encou
Additional Specifications HL7 CDA ® Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1 – US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=398

HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3 - US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=385

HL7 CDA® R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes - US Realm: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492

HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1: https://www.hl7.org/fhir/us/core/index.html

HL7 FHIR US Core Encounter: http://hl7.org/fhir/us/core/StructureDefinition-us-core-encounter.html. MustSupport for the following elements: Encounter status, Classification of Encounter, Encounter type, Encounter subject, Encounter Identifier, Encounter period, Encounter participant type, Participant overseeing the encounter, Primary participant responsible for encounter, Encounter participant individual, Encounter primary performer NPI, Encounter primary performer name, Encounter primary performer professional role, Time period participant participated in the encounter, Reason for the visit, Hospital encounter discharge disposition, Encounter location address

HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm: http://hl7.org/fhir/us/ecr/STU1/Electronic_Initial_Case_Report_(eICR)_Transaction_and_Profiles.html

HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2 - US Realm - the Electronic Initial Case Report (eICR): https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436

Vital Records Birth and Fetal Death Reporting FHIR - US Realm: https://build.fhir.org/ig/HL7/fhir-bfdr/index.html

HL7 Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2 - US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=320

HL7 CDA® R2 Implementation Guide: Birth and Fetal Death Reporting, Release 1, STU (Release 2 - US Realm): https://www.hl7.org/implement/standards/product_brief.cfm?product_id=387

IHE Quality, Research and Public Health Technical Framework Supplement: Birth and Fetal Death Reporting-Enhanced (BFDR-E) Revision 3.1: (https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf)
Current Use Extensively used in production environments
Supporting Artifacts Level 2 – at scale, or in more widespread production use (routinely collected already) on several different EHR/HIT systems.

Widely available in EHR systems.

These data elements exist in FHIR with a FHIR Maturity level of 2 for the Encounter Resource data elements. FHIR Encounter Resource: https://www.hl7.org/fhir/encounter.html

ONC Interoperability Standards Advisory (ISA) - Sending Health Care Survey Information to Public Health Agencies. NHCS in ISA: https://www.healthit.gov/isa/sending-health-care-survey-information-public-health-agencies

ONC Interoperability Standards Advisory (ISA) - Reporting Birth and Fetal Death to Public Health Agencies. BFDR-E in ISA: https://www.healthit.gov/isa/reporting-birth-and-fetal-death-public-health-agencies

Promoting Interoperability Programs Eligible Hospitals and Critical Access Hospitals are required to, and Merit-based Incentive Payment System (MIPS) participants may optionally, report on any two measures under the Public Health and Clinical Data Exchange objective of these programs. The § 170.315(f)(5) – Transmission to public health agencies – electronic case reporting certification criteria in the 2015 Edition Final Rule and the ONC Cures Act Final Rule, the § 170.315(f)(7) – Transmission to public health agencies – health care surveys, and the § 170.315 (f)(4) – Transmission to Cancer Registries are three such options to meet these measures. Certified Health IT Product List: https://chpl.healthit.gov/#/search
CHPL Cancer: Cancer: https://chpl.healthit.gov/#/search: 170.315 (f)(4): Transmission to Cancer Registries
Retired | 170.314 (f)(5): Optional - ambulatory setting only - cancer case information
Retired | 170.314 (f)(6): Optional - ambulatory setting only - transmission to cancer registries)

The current standard for § 170.315(f)(5), as listed in ONC’s 2020 Interoperability Standards Advisory Reference Edition, is HL7® CDA® R2 Implementation Guide: Public Health Case Report, Release 2: the Electronic Initial Case Report (eICR), Release 1, STU Release 1.1. ONC’s Certified Health IT Product List (CHPL) lists 73 EHR or HIT Module products certified to (f)(5) using this standard. eCR IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436

The current standard for § 170.315(f)(7), as listed in ONC’s 2020 Interoperability Standards Advisory Reference Edition, is HL7® CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 DSTU Release 1.2 - US Realm. ONC’s Certified Health IT Product List (CHPL) lists 116 EHR or HIT Module products certified to (f)(5) using this standard. NHCS IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=385

The current standard for § 170.315 (f)(4), as listed in ONC’s 2020 Interoperability Standards Advisory Reference Edition, is HL7 CDA® R2 IG: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, R1, DSTU Release 1.1 - US Realm. ONC’s Certified Health IT Product List (CHPL) lists 288 EHR or HIT Module products certified to (f)(4) using this standard. Cancer Reporting IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=398

These three widely adopted CDA standards have many of the Encounter data elements contained on this form as Shall (required) or Should (best practice to include if available) conformance criteria, which demonstrates the maturity of these commonly exchanged data elements.

In production use: EPIC stork module (obstetrics) for birth reporting. Facility worksheets that collect medical information for live birth and fetal death: https://www.cdc.gov/nchs/data/dvs/facility-worksheet-2016-508.pdf. EPIC stork module (obstetrics) for birth reporting: https://www.epic.com/software#PatientEngagement.
https://www.hl7.org/fhir/encounter.html NHCS in ISA: https://www.healthit.gov/isa/sending-health-care-survey-information-public-health-agencies BFDR-E in ISA: https://www.healthit.gov/isa/reporting-birth-and-fetal-death-public-
Number of organizations/individuals with which this data element has been electronically exchanged 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.
Supporting Artifacts Level 2 – exchanged between 4 or more different EHR/HIT systems. More routinely exchanged between multiple different systems can justify adding to next draft version.

Several cancer registries have received cancer reports from at least one provider (per internal technical and programmatic documentation) that include these data elements: Encounter period, Encounter participant type, Primary participant responsible for encounter, Encounter participant individual, Encounter primary performer NPI, Encounter primary performer name, Encounter location address.

HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2 - US Realm - the Electronic Initial Case Report (eICR) is currently implemented in 5,400+ reporting sites nationally and exchanges Encounter information including: Classification of Patient Encounter, Encounter type, Encounter subject, Encounter Participant Type, Encounter Participant Individual, Participant Overseeing the Encounter, Encounter Primary Performer NPI, Encounter Primary Performer Name, Encounter Primary Performer Professional Role, Encounter Location Address, Reason for Visit, Hospital Encounter Discharge Disposition. HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2 - US Realm - the Electronic Initial Case Report (eICR): https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436

In production use: EPIC stork module (obstetrics) for birth reporting: https://www.epic.com/software#PatientEngagement

As part of Cancer Reporting CDA IGs:
IHE Connectathons 2010-2020.
HIMSS Interoperability Showcase 2010-19
Public Health Informatics Conference Interoperability Showcase 2014, 2016, 2018
NACCHO 360X Interoperability Demonstrations, 2020

As part of National Health Care Surveys CDA IGs:
IHE Connectathons 2019-2020

IHE Connectathon integration profiles for Birth and Fetal Death Reporting - Enhanced (2013 - 2020). IHE Connectathons: Found in 'New Search', filter by 'Select an integration profile = Birth and Fetal Death Reporting-Enhanced' https://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile

HL7 FHIR Connectathon results (Sept 2020): birth and fetal death reporting results testing between electronic birth registration system vendors (FHIR). FHIR Connectathons: https://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track

HIMSS Interoperability showcase BFDR-E (2018 – 2019)

NACCHO 360X Interoperability Demonstrations for Birth and Fetal Death reporting 2020 between NextGen and two state electronic birth registrations system vendors using FHIR.
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436 EPIC stork module (obstetrics) for birth reporting: h
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) None
Restrictions on Use (e.g. licensing, user fees) None
Privacy and Security Concerns None
Estimate of Overall Burden Low.

EHRs use encounters as a fundamental organizing structure so this set of encounter data elements are already "baked in" to EHRs used by providers. Providers and EHR products will experience no burden for something they already use widely other than EHR companies extending the availability of these data elements to USCDI data sets.

Several existing IGs, as listed, require the exchange of this data element.

The Promoting Interoperability Programs Objective 8 - Public Health and Clinical Data Registry Reporting, measures 3 -: Electronic Case Reporting and 4: Public Health Registry Reporting require these data elements.

Encounter information is routinely communicated in HL7 CDA Documents and some FHIR API transactions.
Other Implementation Challenges None

Comment

Submitted by HCapon on 2023-04-13

PACIO Project Support to Advance Encounter Identifier

  • Data Class: Encounter (Draft V4) 
 
  • Data Element: Encounter Identifier (Draft V4) 
 
  • Recommendation: Include the “Encounter Identifier” data element under the Encounter Information Data Class in USCDI V4 and create data elements for encounter status, encounter subject, encounter participant, and reason for encounter under the Encounter Information Data Class in a future version of the USCDI. 
 
  • Rationale: The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange. The PACIO Community has published a Re-Assessment Timepoints FHIR implementation guide (http://hl7.org/fhir/us/pacio-rt/) that profiles the US Core Encounter to support the representation of subsets of the longer encounters such as those found in post-acute care, behavioral health, and other residential settings. Because they represent parts of the larger encounter that is already a data class within USCDI, we believe that field-level requirements within that guide provide anecdotal support to proposed encounter data elements, including status, subject, identifier, participant, and reason for encounter. By providing real-world experience from implementations of the standard, we hope the Re-Assessment Timepoints implementation guide will help motivate the inclusion of these Encounter data elements within a future version of USCDI. The PACIO Community also believes that the concept of an encounter subset that is at the core of the Re-Assessment Timepoints implementation guide is a useful data element to include within USCDI and we will propose this as a new data element. 

Submitted by nedragarrett_CDC on 2023-04-06

CDC's Consolidated Comment for USCDI v4

  • Shared priority for CDC, CMS, and ASPR (via all hazards work with CDC)
Encounter identifiers are critical for providing context to other clinical data and supporting linking of data across care settings, distinguishing between encounters, as well as tracking of data, including between acute, post-acute and other care settings.  All these activities are important for supporting interoperability, public health reporting, and quality measurement. Furthermore, encounter identifiers can support public health emergency activities. Encounter identifiers are absolutely essential for calculating measures of patient safety and quality that are under surveillance because those identifiers enable the attribution of an event to a particular patient-admission or discharge 
  • Use Cases:
  1. Patient safety quality measurement and public health surveillance via NHSN hospital COVID reporting to NHSN  & AUR surveillance via NHSN
  2.  Bidirectional Referral to CDC lifestyle change programs
  3. Clinical-community linkages
  •  Comments from NACCHO: NACCHO supports the inclusion of the data element Encounter Identifier and believes that an additional use case: local disease burden (number of people vs. total health care utilization), should be considered 
  •  Comments from CSTE: CSTE strongly recommends inclusion of encounter identifier in USCDI v4. This field would be exceedingly helpful in matching eCR data back to the encounter from which it derived. This will be critical for data quality improvement and troubleshooting as eCR implementation scales up across the US

Submitted by Svellanky on 2022-09-29

CMS-CCSQ Continued Support for Encounter Identifier

CMS-CCSQ recommends reclassification of this data element to Level 2 and continues to find value in the addition of the data element to USCDI. This data element was previously identified as a CMS-CDC joint priority. Encounter identifiers are critical for providing context to other clinical data and supporting linking of data across care settings, distinguishing between encounters, as well as tracking of data, including between acute, post-acute and other care settings. All of these activities are important for supporting interoperability, quality measurement, and public health reporting. Furthermore, encounter identifiers (IDs) can support public health emergency activities, which is a stated ONC USCDI v4 priority. Maturity:
  • Current standards:
    • HL7 FHIR US Core Implementation Guide STU4, STU5 based on FHIR R4, Encounter Profile must support an encounter identifier (https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-encounter.html)
    • Although there is no universal formatting standard for encounter IDs, the current state of “standardization” is sufficient to support the stated uses of linking and contextualizing data.
Current uses, exchange, and use cases: CMS recognizes that there may be variation in how encounter identifiers are formatted across facilities (i.e., there is not yet one, universal formatting standard), but the information provides context to the granular data exchanged – for example, did this data come from two distinct encounters or the same encounter – and enables linking those shared data with other relevant information. Encounter Identifiers are submitted for CMS eCQMs to support distinguishing between episodes of care when multiple episodes of care are submitted for a quality measure. This data element is also used for public health reporting.

Submitted by PACIO-Project on 2022-09-28

Support to Advance Encounter Identifier

  • The PACIO (Post-Acute Care Interoperability) Project, established February 2019, is a collaborative effort between industry, government, and other stakeholders, with the goal of establishing a framework for the development of FHIR implementation guides to facilitate health information exchange.
  • The PACIO Community has published a Re-Assessment Timepoints FHIR implementation guide (http://hl7.org/fhir/us/pacio-rt/) that profiles the US Core Encounter to support the representation of subsets of the longer encounters such as those found in post-acute care, behavioral health, and other residential settings. Because they represent parts of the larger encounter that is already a data class within USCDI, we believe that field-level requirements within that guide provide anecdotal support to proposed encounter data elements, including status, subject, identifier, participant, and reason for encounter. By providing real-world experience from implementations of the standard, we hope the Re-Assessment Timepoints implementation guide will help motivate the inclusion of these Encounter data elements within a future version of USCDI.
  • The PACIO Community also believes that the concept of an encounter subset that is at the core of the Re-Assessment Timepoints implementation guide is a useful data element to include within USCDI and we will propose this as a new data element.

Submitted by nedragarrett_CDC on 2022-09-28

CDC's comment on behalf of CSTE

CSTE Comment:
  • CSTE strongly recommends inclusion of encounter identifier in USCDI v4. This field would be exceedingly helpful in matching eCR data back to the encounter from which it derived. This will be critical for data quality improvement and troubleshooting as eCR implementation scales up across the US.

Submitted by nedragarrett_CDC on 2022-04-28

CDC-CMS Shared Priority

Encounter identifier is CDC-CMS shared priority to be included in V3.

Submitted by nedragarrett_CDC on 2022-04-26

CDC's comment on behalf of CSTE

CSTE strongly recommends inclusion of encounter identifier in USCDI v3. This field would be exceedingly helpful in matching eCR data back to the encounter from which it derived. This will be critical for data quality improvement and troubleshooting as eCR implementation scales up across the US.

Submitted by nedragarrett_CDC on 2022-04-26

CDC's Consolidated Comment

Importance: The Encounter Identifier helps narrow the patient’s health information to a particular encounter so that only relevant information is sent from the patient’s record. Facilitates accurate linking of data across encounters. This is important for at least two reasons: (1) unnecessary information from the patient’s health record should not be sent, (2) extra information sent requires a lot of effort to process to get to the necessary information. This is not ideal for the data sender or the data receiver. Feasibility: Since Encounter Identifier is required in HL7 CCD and C-CDA documents (as a “SHALL” and “SHOULD”), EHRs likely already support this data element. Examples of program use: CDC Division of Healthcare Quality Promotion (DHQP) Hypoglycemia Measure Additional Technical Specifications: HL7 FHIR Health Care Surveys Content Implementation Guide (http://hl7.org/fhir/us/health-care-surveys-reporting/2022Jan/); HL7 FHIR Central Cancer Registry Reporting Content Implementation Guide (http://hl7.org/fhir/us/central-cancer-registry-reporting/2022Jan/).

Submitted by sg999 on 2022-03-22

CMS-CCSQ Support for Encounter Identifier

CMS-CCSQ recommends reclassification of this data element to Level 2. Encounter identifiers are critical for linking data, distinguishing between encounters, as well as tracking of data. Encounter identifiers provide important contextual information to support interoperability, quality measure reporting, and public health reporting. Maturity:
  • Current standards:
  • Current uses, exchange, and use cases: CMS recognize that there may be variation in how encounter identifiers are formatted across facilities (i.e., there is not yet one, universal formatting standard), but the information provides context to the granular data exchanged – for example did this data come from two distinct encounters or the same encounter—and enables linking those shared data with other relevant information. Encounter Identifiers are submitted for CMS eCQMs to support distinguishing between episodes of care when multiple episodes of care are submitted for a quality measure.

Submitted by nedragarrett_CDC on 2021-09-28

Unified Comment from CDC

  • Data element description: Encounter Identifier is defined by HL7 US Core as the identifier(s) by which this encounter is known and US Core notes that this is a business identifier, not a resource identifier (http://hl7.org/fhir/us/core/StructureDefinition-us-core-encounter-definitions.html#Encounter.identifier).  
  • General Comment: Encounter Identifier is a Must Support data element in the US Core Encounter Profile. Encounter identifier is a fundamental and critically important data element for the MedMorph use case of Health Care Surveys. Cancer Registries and we suspect many other use cases use Encounter Identifier to resolve duplicate records, among other uses.  
  • Estimate the number of stakeholders who capture, access, use or exchange this data element or data class: The encounter identifier is generated by all EHRs that this commenter is aware of including all major EHR products that together comprise over 80% of inpatient and ambulatory EHR US market share.  
  • Additional Use Cases: Among many other clinical and payment related use cases, Da Vinci Payer Data Exchange 1.0.0 - STU1 (http://hl7.org/fhir/us/davinci-pdex/USCoreEncounter.html) uses Encounter Identifier.  
  • Additional Applicable Standards: Da Vinci Payer Data Exchange http://hl7.org/fhir/us/davinci-pdex/STU1/

Log in or register to post comments