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.
Estimate the breadth of applicability of the use case(s) for this data element
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.
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.
Estimate the breadth of applicability of the use case(s) for this data element
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
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
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
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.
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
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
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.
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.
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:
Patient safety quality measurement and public health surveillance via NHSN hospital COVID reporting to NHSN & AUR surveillance via NHSN
Bidirectional Referral to CDC lifestyle change programs
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
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.
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.
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.
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.
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.
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/).
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.
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 kelly.clarke@j… on
Feedback
Agree and support this new data element. This will help with care delivery and the future of FHIR resources.