Encounter Information

Encounter Diagnoses

The USCDI V3 notion of “encounter diagnosis” needs further refinement to differentiate different types of encounter diagnoses. Outpatient encounter diagnoses need to be differentiated from inpatient encounter diagnoses because inpatient encounter diagnoses include both admission diagnoses and discharge diagnoses. In other care settings, such as Physical Therapy, they utilize three different types of encounter diagnoses:  the billing diagnoses, medical diagnoses, and treating diagnoses. The proposed data element is not granular enough to support valuable interoperability.

Greater standardization of the vocabulary used to express diagnoses also needs to be addressed.  Current standards do not provide implementers with adequate and consistent guidance on mappings between ICD-10 and SNOMED CT.  Duplicating the expression of problems in both SNOMED CT and ICD-10 adds burden and introduces complexities for information exchange. ICD-10, maintained by the World Health Organization, is the primary vocabulary for encoding diagnoses around the globe, and the vocabulary becomes increasingly expressive as it matures.  SNOMED CT is well positioned to represent clinical findings and other non-diagnoses-related concepts. Focusing on the use of ICD for all diagnoses, without mandating it be translated to SNOMED CT would reduce a great deal of burden, better support interoperability, and allow greater consistency across V2, CDA, FHIR and other administrative information such as explanation of benefits.

USCDI V3 Comment 20220429_0.pdf

CMS appreciates the support…

CMS appreciates the support for inclusion of the Encounter Information data class and agrees with the need for clarity surrounding the data elements. Regarding encounter diagnosis, CMS’s intent of the original submission was to represent the actual coded diagnoses on the encounter for clinical or billing purposes. As Cerner notes, this 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”). We agree with Cerner’s recommendation for the naming of the data element and the description of the data element to clarify the intent. We also agree, and recommended, inclusion of ICD-10-CM and SNOMED CT terminology as the applicable standards for the data element.  
CMS also recognizes the distinction between this data element an a “reason for visit” data element, and supports consideration for inclusion of a distinct reason for visit data element in a future USCDI version.
Regarding the Encounter type data element, CMS’s intent of the original submission was to represent types of services provided, and we therefore agree a definition similar to the US Core Encounter Type value set definition is appropriate. In our submission, we note the following standards often used to represent Encounter Type: SNOMED CT, HCPCS, CPT.

CMS appreciates the support for inclusion of the Encounter Information data class and agrees with the need for clarity surrounding the data elements. Regarding encounter diagnosis, CMS’s intent of the original submission was to represent the actual coded diagnoses on the encounter for clinical or billing purposes. As Cerner notes, this 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”). We agree with Cerner’s recommendation for the naming of the data element and the description of the data element to clarify the intent. We also agree, and recommended, inclusion of ICD-10-CM and SNOMED CT terminology as the applicable standards for the data element.  
CMS also recognizes the distinction between this data element an a “reason for visit” data element, and supports consideration for inclusion of a distinct reason for visit data element in a future USCDI version.
Regarding the Encounter type data element, CMS’s intent of the original submission was to represent types of services provided, and we therefore agree a definition similar to the US Core Encounter Type value set definition is appropriate. In our submission, we note the following standards often used to represent Encounter Type: SNOMED CT, HCPCS, CPT.
 

Response to Comment on Encounter Diagnosis

Align Diagnoses with Problems?
How is Encounter Information.Encounter Diagnosis different from the Problems.Problems? Encounter Diagnosis lists SNOMED and ICD-10 as standards. However, Problems only includes SNOMED. Why the difference - should ICD 10 be added to Problems? Is the Encounter Diagnosis supposed to just be a link or reference to the Problems class? There is inconsistency on what has been labeled as "duplicate" or added to USCDI.

CMS's submission for encounter diagnoses was intended to represent diagnoses associated with a specific encounter. This list will likely overlap with Problem lists, but problem lists may be more expansive to include additional problems, diagnoses, etc of a patient, regardless of the association to a specific encounter. CMS recommended ICD-10 and SNOMED CT terminology as applicable standards to ensure diagnoses captured in the billing and clinical modules of an EHR could be exchanged. CMS also recommends allowing for ICD-10 terminology to be used for Problems, to better align across USCDI data elements and with current practice.

Response to Comment on Encounter Diagnosis

This data element raises several questions. Physical therapists have a movement system diagnosis which helps to guide treatment; physical therapist diagnosis; medical diagnosis; etc. What is the diagnosis that should be reported? Is it the primary medical diagnosis? Or both the physical therapist and primary medical professional? Or, if the patient is post-operative, is the surgical or medical diagnosis reported? We also question why encounter diagnosis includes both SNOMED and ICD-10. Is it the billing diagnosis (diagnosis included on the claim); is it the primary reason why the individual is receiving treatment; is it the referring physician’s diagnosis (if there is a referring physician); or? We request that this be clarified in the final version what diagnosis is expected to be reported. We also request clarification as to whether this is intended to be a “repeatable” element, or only for the “primary” or “principal” diagnosis. If repeatable, some other data elements may be needed (e.g., ranking and/or type).

CMS clarifies that the intent of our submission for Encounter Diagnosis data element was to represent diagnoses associated with a specific encounter. In FHIR US Core, multiple diagnoses can be included for an encounter. CMS recommended ICD-10 and SNOMED CT terminology to ensure diagnoses captured in the billing and clinical modules of an EHR could be exchanged.

Response to Comment on Encounter Diagnosis

In the detailed description of this data element reference is made to Primary Diagnosis and Discharge Diagnosis. Are these specifications of diagnosis category required as a part of the Encounter Diagnosis data element, or can this additional specification be optionally included if available?

CMS clarifies that the intent of our submission for Encounter Diagnosis data element was to represent diagnoses associated with a specific encounter. We acknowledge that primary diagnosis can also be specified in the FHIR US Core Encounter profile, and support that additional specification be optionally included if available. 

Encounter Diagnosis

Applicable Standard(s): SNOMED-CT, HCPCS, CPT, HL7, ICD-10-CM, HSLOC, VSAC
Comments:
• We would need to consider capturing this variable in order to support the following domain related to Paul Coverdell National Acute Stroke Program/American Hospital Association’s (AHA) Get With The Guidelines (GTWG). The goal is to reduce gaps in stroke care across the continuum of care in states with high burden populations.
• The information captured from stroke patients and those who encounter mobility related issues and are at risk of multiple hospitalizations due to post-discharge complications can help in reducing the gaps in care and to plan quality improvement efforts.

# Domain # of Variables Variable Details Required or Optional
1 Readmissions 1 1. If readmitted, were any of readmissions due to: 1. Fall, 2. Deep vein thrombosis/pulmonary embolism/blood clot, 3. Carotid Intervention, 4. Acute Myocardial Infarction, 5. Heart Failure, 6. Infection/Sepsis, 7. Blood pressure, 8. Pneumonia, 9. Trans Ischemic Attack, 10. Atrial Fibrillation, 11. Other cardiac survey event, 12. Other surgical procedure, 13. Urinary tract infection, 14. Unknown, 15= Other) Optional
Use-Case Justification: The most challenging part is capturing the information post-hospital discharge for acute stroke patients. A lot of the pre-hospital care is captured through National Emergency Medical Services Information System (NEMSIS), a national database that stores EMS data from the U.S. States and Territories). The follow-up elements proposed above have been developed as a part of the Paul Coverdell National Acute Stroke Program (link provided below) and captured within EHR for submission into American Heart Association’s (AHA) Get With The Guidelines (GTWG) module. The ability to extract the follow-up encounter related dates would help with the identification of gaps in post-hospital discharge date for stroke patients and plan strategies for Quality Improvement efforts.
https://www.cdc.gov/dhdsp/programs/stroke_registry.htm

This field is for general comments on this specific data element. 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_vFinal_04.14.2021_2.docx

Align Diagnoses with Problems?

How is Encounter Information.Encounter Diagnosis different from the Problems.Problems? Encounter Diagnosis lists SNOMED and ICD-10 as standards. However, Problems only includes SNOMED. Why the difference - should ICD 10 be added to Problems? Is the Encounter Diagnosis supposed to just be a link or reference to the Problems class? There is inconsistency on what has been labeled as "duplicate" or added to USCDI.

This data element raises…

This data element raises several questions.

Physical therapists have a movement system diagnosis which helps to guide treatment; physical therapist diagnosis; medical diagnosis; etc. What is the diagnosis that should be reported? Is it the primary medical diagnosis? Or both the physical therapist and primary medical professional? Or, if the patient is post-operative, is the surgical or medical diagnosis reported?

We also question why encounter diagnosis includes both SNOMED and ICD-10. Is it the billing diagnosis (diagnosis included on the claim); is it the primary reason why the individual is receiving treatment; is it the referring physician’s diagnosis (if there is a referring physician); or? We request that this be clarified in the final version what diagnosis is expected to be reported.

We also request clarification as to whether this is intended to be a “repeatable” element, or only for the “primary” or “principal” diagnosis. If repeatable, some other data elements may be needed (e.g., ranking and/or type).

Requirement for specified Primary and/or Discharge Diagnosis?

In the detailed description of this data element reference is made to Primary Diagnosis and Discharge Diagnosis. Are these specifications of diagnosis category required as a part of the Encounter Diagnosis data element, or can this additional specification be optionally included if available?

MedMorph's need for Delivery and Pregnancy Information class

Pregnancy Outcome is specific to if an infant is living at time of report.  This is relevant to noting the infant's survival when birth certification information is being documented. This item is on the national standard worksheet capturing medical information that jurisdictions use to report.

As commented on other natality reporting data elements submitted to USCDI, it is important to recognize that birth and delivery events information may be captured within specific areas of a healthcare system such as labor and delivery summaries and prenatal care records. To help lessen the burden of implementations and queries of these events is the reason to propose a new Delivery and Pregnancy Information class where these specific data elements may be captured.  Another option for data class instead of 'Encounter Diagnosis' would be ‘Observation’.  However, as previously stated an ideal fit for natality reporting would be within a specific class for this specific life event.

National worksheet for reporting of live birth and US standard birth certificate:
https://www.cdc.gov/nchs/data/dvs/facility-worksheet-2016-508.pdf,
https://www.cdc.gov/nchs/data/dvs/birth11-03final-ACC.pdf

Additional relevant specification for this data element includes HL7 and IHE standards listed below.

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

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

Vital Records Common Profiles Library FHIR IG: http://build.fhir.org/ig/HL7/fhir-vr-common-ig/branches/master/index.html

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

Birth Defect Reporting FHIR IG: https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/index.html

HL7 CDA® R2 Implementation Guide: Ambulatory and Hospital Healthcare Provider Reporting to Birth Defect Registries Release 1 , STU 2 -US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=428

Below lists examples of artifacts of where this data element is collected.

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

EPIC FHIR APIs for patient, vitals, obstetric details:
https://fhir.epic.com/Specifications?api=932
https://fhir.epic.com/Specifications?api=968
https://fhir.epic.com/Specifications?api=966

BFDR-E in ISA:
https://www.healthit.gov/isa/reporting-birth-and-fetal-death-public-health-agencies