Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-28186

Define a primary Vs principal Vs other type of encounter-specific condition

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive
    • Icon: Medium Medium
    • US Core (FHIR)
    • 3.1.1
    • Cross-Group Projects
    • US Core Encounter Profile
    • encounter, suggest this is an errata
    • Hide

      The commenter is suggesting that we either add use and rank extensions to Condition in order to  mimic the structure for Encounter.diagnosis or add Encounter.diagnosis to US Core as a Must Support element.

      Implementer (EHR) feedback drove the decision to not make Encounter.diagnosis a Must Support element. We document that in the guidance:

      To search for an encounter diagnosis, query for Condition resources that reference the Encounter of interest and have a category of encounter-diagnosis. An example search is shown in the Condition Quick Start section.

       

      US Core defines the minimal set of constraints and will not add the elements or extensions if the EHR/HIT systems that are a source of patient data don't support them.  However, It is reasonable to add the Encounter.diagnosis element for a particular use case in a dependent guide like the commenter described for QI Core or define extensions for Condition to reproduce this capability.

      Show
      The commenter is suggesting that we either add use and rank extensions to Condition in order to  mimic the structure for Encounter.diagnosis or add Encounter.diagnosis to US Core as a Must Support element. Implementer (EHR) feedback drove the decision to not make Encounter.diagnosis a Must Support element. We document that in the guidance: To search for an encounter diagnosis, query for Condition resources that reference the Encounter of interest and have a category of encounter-diagnosis. An example search is shown in the Condition Quick Start section.   US Core defines the minimal set of constraints and will not add the elements or extensions if the EHR/HIT systems that are a source of patient data don't support them.  However, It is reasonable to add the Encounter.diagnosis element for a particular use case in a dependent guide like the commenter described for QI Core or define extensions for Condition to reproduce this capability.
    • Eric Haas/Floyd Eisenberg: 16-0-0

    Description

      US Core – lists as MUST SUPPORT US-Core-R4 [Encounter.reasonCodehttps://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-encounter-definitions.html[Reason the encounter takes place, expressed as a code. For admissions, this can be used for a coded admission diagnosis.]|https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-encounter-definitions.html]However, to define a primary, principal, working, etc. diagnosis, it seems an extension is required. First, the extension links are broken. Second, this remains problematic. As currently included in Encounter.reasonCode:

      • Codeable Concept SHOULD be taken from valueset-encounter-reason(SNOMED clinical findings, procedures, context-dependent categories, events).
      • The diagnosis can be coded using Encounter.reasonCode. However, there is no role.
      • The path could be using the registry of standard extensions that can be found in the FHIR specification and additional extensions may be registered on the HL7 FHIR registry at http://hl7.org/fhir/registry. Taking that path I found a lot of broken links, but eventually found this: https://registry-api.fhir.org/open/StructureDefinition/98f84aa0-0137-4f2c-82e3-66b403432301?_format=json.
      • Reviewing the details, it basically assigns a sequence to the diagnosis and it can be a billing diagnosis, but sequence is not detailed. Note – Claim includes a Claim.diagnosis.sequence; Encounter includes Encounter.diagnosis.rank – both with similar but different definitions.
      • US Core does not specifically support Encounter.diagnosis which does have Encounter.diagnosis.rank (similar to sequence) and Encounter.diagnosis.role that allows specifying the role (admitting, discharge, billing, etc.).
      • QI-Core took the path of Encounter.diagnosis with its respective role,rank and added onAdmission parallel to Claim.diagnosis.

      Request US Core to reconsider and use the established FHIR mechanism to define Encounter.diagnosis with its children - using Encounter.reasonCode requires unnecessary extensions to get to the same resolution and that seems unreasonable burdensome.  This seems to be an errata in original modeling.

      Attachments

        Activity

          People

            Unassigned Unassigned
            feisenberg Floyd Eisenberg
            Floyd Eisenberg
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: