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

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Considered for Future Use
    • Priority: Medium
    • US Core (FHIR)
    • 3.1.1
    • Cross-Group Projects
    • US Core Encounter Profile
    • encounter, suggest this is an errata
    • Hide

      Reverted previous resolution: Considered for Future Use made 2020-11-12 00:00:00.0 with vote Eric Haas/Drew Torres: 6-0-0//(Impact: null; Category: null; Version: null)//Will update when there is consensus approach

       

      Note that the extension and guidance in reasonCode are all directly from the base FHIR specification and any issue with those should be logged with the PA WorkGroup.
        
       
      reopen to redisposition as 'deferred' from 'change required' as intended

      Show
      Reverted previous resolution: Considered for Future Use made 2020-11-12 00:00:00.0 with vote Eric Haas/Drew Torres: 6-0-0//(Impact: null; Category: null; Version: null)//Will update when there is consensus approach   Note that the extension and guidance in reasonCode are all directly from the base FHIR specification and any issue with those should be logged with the PA WorkGroup.      reopen to redisposition as 'deferred' from 'change required' as intended
    • Eric Haas/Drew Torres: 6-0-0

      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.

            Assignee:
            Unassigned
            Reporter:
            Floyd Eisenberg
            Floyd Eisenberg
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: