Encounter Information

NCPDP Comments

• NCPDP recommends adding a data element “Encounter Reason” under the data class “Encounter Information”. Pharmacists document "encounter reasons" in the NCPDP/HL7 Pharmacist eCare Plan using SNOMED CT.  These SNOMED CT codes are in the NLM VSAC OID 2.16.840.1.113762.1.4.1096.182.  
• NCPDP recommends adding a data element “Encounter Type” under the data class “Encounter Information”. Pharmacists document "encounter type" in the NCPDP/HL7 Pharmacist eCare Plan using SNOMED CT.  These SNOMED CT codes are in the NLM VSAC OID 2.16.840.1.113762.1.4.1096.151. 
• NCPDP recommends adding a data element “Encounter Class” under the data class “Encounter Information”. Pharmacists document "encounter class" in the NCPDP/HL7 Pharmacist eCare Plan using SNOMED CT.  These SNOMED CT codes are in the NLM VSAC OID 2.16.840.1.113762.1.4.1096.152. 

Lantana Consulting Group Comment

Lantana recommends adding the Encounter Identifier data element to USCDI version 3. An Encounter Identifier is critically important to linking and tracking data, distinguishing between encounters that represent multiple episodes of care and evaluating care that takes place either short or long-term. This information is important for quality measurement and public health reporting. It is widely implemented by the industry because of its value and is categorized as “must support” in the FHIR R4 US Core Implementation Guide STU4 (https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-encounter-definitions.html#Encounter.identifier).

NCPDP Comments on USCDI draft V3

NCPDP requests Encounter Class and Encounter Reason also be added to Draft Version 3.

This field is for general…

This field is for general comments on this specific data class. To submit new USCDI data classes and/or data elements, please use the USCDI ONDEC system: https://healthit.gov/ONDEC

NCPDP Comment

NCPDP requests Encounter Class and Encounter Reason also be added to Draft Version 2.

time, type, and diagnosis

The CDC Division for Heart Disease and Stroke Prevention and the Million Hearts® 2022 Hearts national initiative (co-led by and the Centers for Medicare & Medicaid Services) uses this data as it is available for monitoring and evaluation to prevent 1 million heart attacks and strokes in 5 years. Furthermore, the CDC plans to leverage this data further in the future for surveillance and epidemiology studies if advanced through policy and available from EHRs. The Multi-state EHR-based Network for Disease Surveillance (MENDS) pilot will use electronic health record (EHR) data collected in clinical settings leading to a real-time, chronic disease surveillance model to plan and evaluate short-term outcomes of policies and program interventions. Initial diagnosis date and place will be very useful for chronic conditions, as it will shed light on disease progression, quality of life, treatment effectiveness etc.This field is for general comments on this specific data class. To submit new USCDI data classes and/or data elements, please use the USCDI ONDEC system: https://healthit.gov/ONDEC

USCDI_Version_2_Draft_Template for Comments_DHDSP_MENDS_04.15.2021.docx

Cerner Corporation USCDI Draft V2 Comments - Encounter Info

Provided below are Cerner's comments on the USCDI draft V2 proposals for the Encounter Information data class. Cerner's full public comments on the USCDI draft V2 have been posted on the USCDI general comments section.   Cerner appreciates ONC’s proposal to add the Encounter Information data class and supports its inclusion in USCDI V2. We agree that encounter information for the elements proposed is commonly recorded and exchanged today using consensus standards and the data is of sufficient importance to clinical care to warrant immediate adoption. However, there are some critical points of clarity needed to ensure a clear, consistent understanding of the scope and intent of its constituent data elements for the industry.   This is especially true of the proposed Encounter Diagnosis data element. The current description of “Represents the primary reason for a healthcare encounter and associated diagnoses, represented by a diagnosis code” (https://www.healthit.gov/isa/uscdi-data/encounter-diagnosis) appears to consolidate multiple concepts that should be represented as distinct data elements in USCDI. Specifically, the “primary reason for a healthcare encounter” portion of the description appears to align most closely with the concept of a “reason for visit,” which is normally either patient-stated or a general observation from the clinical care team for why the patient sought care and may often be a free text/narrative entry that is rarely codified. This concept would align most closely with the reasonCode attribute of the Encounter Profile in HL7 FHIR US Core, and with the Reason for Visit and/or Chief Complaint section in HL7 CDA C-CDA. It is also distinct from the actual coded diagnoses on the encounter for clinical or billing purposes, which would align with the diagnosis attribute of the Encounter Profile in HL7 FHIR US Core (i.e., the “list of diagnosis relevant to this encounter”) and the Encounter Diagnosis (V3) entry in HL7 CDA C-CDA. The distinction between these concepts is an important one and should be accommodated in USCDI.   Accordingly, we highly recommend that the Encounter Diagnosis data element be explicitly defined as encompassing the list of all coded diagnoses for the encounter whether for clinical, billing, or administrative purposes. In line with that definition, the data element should also be specifically named as “Encounter Diagnoses” to directly support the fact it may be comprised of a list of relevant diagnoses and not a singular diagnosis. It is sensible that this element encompasses multiple types of coded diagnoses given that HL7 FHIR US Core features an Encounter.diagnosis.use attribute that defines the role of the diagnosis (e.g., admission, discharge, billing, etc.) to the encounter. This means that consumers of the Encounter Diagnosis data element still have the ability to isolate to the specific type of coded diagnoses relevant for their use-case. Further, HL7 CDA C-CDA Encounter Diagnosis (V3) entry also supports multiple diagnoses with priority ranking. Limiting the types of coded diagnoses that could qualify under the data element (e.g., only diagnoses used for billing) would be unnecessarily restrictive and potentially limit the utility of the data element for reference in various downstream use-cases. Lastly, ICD-10-CM and SNOMED-CT should be adopted as the applicable standards for the data element.   With this recommendation, given that the Encounter Diagnoses data element would specifically consist of the full scope of coded diagnoses for the encounter, it will also be necessary to adopt an independent data element for the primary reason for the healthcare encounter as stated by the patient or observed by the clinical care team. We recommend moving forward with adopting that separate concept as the “Reason for Visit” data element under the Encounter Information data class. Since it is generally not a coded observation, it should be adopted without any associated standard. Adopting these independent data elements will achieve multiple purposes including covering the full range of relevant contextual diagnosis information for the encounter, ensuring clarity and sensibility in the types of diagnoses that may be present for an encounter that needs to be supported in these data elements, and aligning with downstream exchange standards.   Regarding the Encounter Type data element, while we support its adoption, we note that there is a need to simplify the definition. We suggest adopting a definition close to that of the US Core Encounter Type value set used for the HL7 FHIR US Core Encounter.type attribute of “a specific code indicating type of service provided” (http://hl7.org/fhir/us/core/ValueSet-us-core-encounter-type.html). Additionally, CPT-4 and SNOMED-CT should be adopted as standards for the Encounter Type data element. Use of these code set systems to represent encounter types is sufficiently mature across the healthcare industry and also aligns with the standards leveraged for both HL7 FHIR US Core within the aforementioned US Core Encounter Type value set, as well as HL7 CDA C-CDA via the EncounterTypeCode value set (2.16.840.1.113883.3.88.12.80.32) leveraged for the Encounter Activity (V3) entry template.

Additional information needed

We request that additional information about what constitutes an “encounter” is included in the final USCDI version. It is imperative that this data class be more definitively described. Moreover, the data elements under encounter information must be more inclusive of qualified health care professionals, including physical therapists.

Encounter diagnosis and time

Overall, the addition of Encounter information in the Draft USCDI V2 is a welcome addition. Could you clarify if Encounter Diagnosis is intended to be a "repeatable" (ie. cardinality 0..* or 1..*)? With a repeated structure, additional attributes may be needed to represent Encounter.diagnosis.use and/or Encounter.diagnosis.rank. Note: there is ongoing discussion in the FHIR community about the relationship between encounter diagnoses and other related FHIR resources.   The current Encounter Time data element definition suggests a mix of possible data types (Date? Start + End Timestamp? Period/duration?). It may may helpful to more precisely represent the allowed/expected/required data types. Note 1: Encounter time periods have a lot of complexity in the context of post acute care settings (with different perspectives from payment and clinical views) that may not be fully captured here. Note 2: Comment level data element submissions exist for Encounter Location Associated Time Period and Encounter Participant Time Period and perhaps should be reconciled with this data element.

Requirement for Discharge Disposition and/or Encounter Location?

Within the data element descriptions there is specification of applicable standards related to Discharge Disposition and Encounter Location.  Are these specific data elements also meant to be required as part of this data class?