Information related to interactions between healthcare providers and a patient.

Data Element
Encounter Participant
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.

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.
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
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-
Extent of exchange 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 PACIO-Project on

Support to Advance Encounter Participant

  • 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

CDC's Consolidated Comment

Supportive of this data element to link providers responsible for a patient’s care across encounters. This use case is valuable for chronic-like infectious conditions like HIV, viral hepatitis, and tuberculosis.

Submitted by nedragarrett_CDC on

Unified Comment from CDC

  • Data element description: Encounter Participant is defined by HL7 US Core as “The list of people responsible for providing the service.” for the encounter. (http://hl7.org/fhir/us/core/StructureDefinition-us-core-encounter-definitions.html#Encounter.participant)
     
  • General Comment: Encounter Participant is a Must Support data element in the US Core Encounter Profile. Encounter Participant for the MedMorph Health Care Surveys use case is used to link participating providers to an ambulatory encounter. and the MedMorph Cancer Registry Reporting use case can use encounter participant to link providers responsible for a patient’s care across encounters.
     
  • 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 Participant.
     
  • Additional Applicable Standards: Da Vinci Payer Data Exchange http://hl7.org/fhir/us/davinci-pdex/STU1/

Submitted by maria.michaels… on

MedMorph submitted multiple…

MedMorph submitted multiple elements for the Encounter class that were modeled directly from the mustSupport elements of the US Core Encounter profile. What has been proposed in USCDI does not reflect the same structure and we believe will cause difficulty by those using the US Core structure. We are struggling to figure out the linkages between USCDI classes. It has been noted that several elements of an Encounter Participant (e.g., role, NPI, name, etc.) are found in the Care Team Member class, but what information would be exchanged using USCDI Encounter Participant?  Can you get a list of the Participant names? Or, is the Encounter Participant element simply "link" to the Care Team Member class where you can get Name, NPI, etc. ? If so, that needs to be defined/explained in USCDI. 

Submitted by kwboone on

Encounter Participant is widely available

This data element appears in HL7 V2 Messages in PV1-7,8,9 and 17 and PD1-4, and are exchanged 40-80% of the time (depending on field) in HIEs I have direct experience with.

In C-CDA Documents it can be found in performer (see performer at https://trifolia.lantanagroup.com/TemplateManagement/View/II/2.16.840.1.113883.10.20.22.1.1/2015-08-01), and as demonstrated in https://github.com/chb/sample_ccdas is widely available and supported in many EHR systems, and other evidence available through participation in prior IHE Connectathons demonstrates that it covered by EHR systems that are available to 85% or more of the provider market.

In FHIR DSTU2 it can be found in Encounter.participant, and in the current US Core (FHIR R4 based) is a must support element (see http://hl7.org/fhir/us/core/StructureDefinition-us-core-encounter.html )

In other words, it is widely available, implemented in software products, and exchanged in physician practice, HIE and in some cases to public health as well.

 

 

 

 

Log in or register to post comments