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

US Core Condition - add optional verificationStatus search parameter

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Published (View Workflow)
    • Medium
    • Resolution: Persuasive with Modification
    • US Core (FHIR)
    • 4.1.0
    • Cross-Group Projects
    • STU
    • US Core Condition Profile
    • Hide

      Background:

      In addition to the commenters description below. US Core Condition Profile documentation states:

      Each Condition must have:

      1. a status of the condition*
      2. a category
      3. a code that identifies the condition
      4. a patient

      *The status element has the following constraints: SHALL be present if verification status is not entered-in-error and SHALL NOT be present if verification Status is entered-in-error.

      Each Condition must support:

      1. a verification status
      2. ....

      The inherited FHIR R4 condition invariants - con-4 and con-5  constrain Condition.clinicalStatus as follows:

      con-3 Warning (base) If category is problems list item, the clinicalStatus should not be unknown category.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-category' and code='problem-list-item').exists() implies clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical' and code='unknown').exists().not()
      con-4 Rule (base) If condition is abated, then clinicalStatus must be either inactive, resolved, or remission. abatement.exists() implies (clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical' and (code='inactive' or code='resolved' or code='remission')).exists())

      With the following comments for the ClinicalStatus element:  

      The data type is CodeableConcept because clinicalStatus has some clinical judgment involved, such that there might need to be more specificity than the required FHIR value set allows. For example, a SNOMED coding might allow for additional specificity. clinicalStatus is required since it is a modifier element. For conditions that are problems list items, the clinicalStatus should not be unknown. For conditions that are not problem list items, the clinicalStatus may be unknown. For example, conditions derived from a claim are point in time, so those conditions may have a clinicalStatus of unknown

      It was also discovered that these invariants do not display in the formal IG profile views.

      Reasoning:

      The documentation in Condition.clinical status is incorrect and needs to be updated to reflect FHIR R4.  Since the base standard does not provide any meaningful guidance on the meaning of an empty clinicalStatus. We will limit the search for active conditions to only those element with an explicit clinicalStatus and document that it omits results when the clinical status is undefined.

      Proposed Changes:

      1) Change to Documentation for Condition

      From:

      Each Condition must have:

      1. a status of the condition*
      2. ...

      *The status element has the following constraints: SHALL be present if verification status is not entered-in-error and SHALL NOT be present if verification Status is entered-in-error.

      To:

      Each Condition must support:

      1. a clinical status of the condition (e.g., this condition active or resolved)
      2. ...

      Profile specific implementation guidance:

      • If category is a problems list item, the clinicalStatus SHOULD not be unknown
      • ....

       

      2) Change implementation Note for searching using the combination of the patient and clinical-status search parameters:

      From:

      Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and all "active" statuses (active,relapse,remission). This will not return any "entered in error" resources because of the conditional presence of the clinicalStatus element.

      To:

      Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and all "active" statuses (active,relapse,remission). This will exclude diagnoses and health concerns without a clinicalStatus specified.

      3) work with publishing to display all the invariants in the snapshot view

      Show
      Background: In addition to the commenters description below. US Core Condition Profile documentation states: Each Condition must have: a status of the condition* a category a code that identifies the condition a patient *The status element has the following constraints: SHALL be present if verification status is not entered-in-error and SHALL NOT be present if verification Status is entered-in-error. Each Condition must support: a verification status .... The inherited FHIR R4 condition invariants - con-4 and con-5  constrain Condition.clinicalStatus as follows: con-3 Warning (base) If category is problems list item, the clinicalStatus should not be unknown category.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-category' and code='problem-list-item').exists() implies clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical' and code='unknown').exists().not() con-4 Rule (base) If condition is abated, then clinicalStatus must be either inactive, resolved, or remission. abatement.exists() implies (clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical' and (code='inactive' or code='resolved' or code='remission')).exists()) With the following comments for the ClinicalStatus element:   The data type is CodeableConcept because clinicalStatus has some clinical judgment involved, such that there might need to be more specificity than the required FHIR value set allows. For example, a SNOMED coding might allow for additional specificity. clinicalStatus is required since it is a modifier element. For conditions that are problems list items, the clinicalStatus should not be unknown. For conditions that are not problem list items, the clinicalStatus may be unknown. For example, conditions derived from a claim are point in time, so those conditions may have a clinicalStatus of unknown It was also discovered that these invariants do not display in the formal IG profile views. Reasoning: The documentation in Condition.clinical status is incorrect and needs to be updated to reflect FHIR R4.  Since the base standard does not provide any meaningful guidance on the meaning of an empty clinicalStatus. We will limit the search for active conditions to only those element with an explicit clinicalStatus and document that it omits results when the clinical status is undefined. Proposed Changes: 1) Change to Documentation for Condition From: Each Condition must have: a status of the condition* ... *The status element has the following constraints: SHALL be present if verification status is not entered-in-error and SHALL NOT be present if verification Status is entered-in-error. To: Each Condition must support: a clinical status of the condition (e.g., this condition active or resolved) ... Profile specific implementation guidance: If category is a problems list item, the clinicalStatus SHOULD not be unknown ....   2) Change implementation Note for searching using the combination of the patient and clinical-status search parameters: From: Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and all "active" statuses (active,relapse,remission). This will not return any "entered in error" resources because of the conditional presence of the clinicalStatus element. To: Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and all "active" statuses (active,relapse,remission). This will exclude diagnoses and health concerns without a clinicalStatus specified . 3) work with publishing to display all the invariants in the snapshot view
    • Brett Marquard/Eric Haas: 15-0-0
    • Enhancement
    • Non-substantive

    Description

      US Core Condition profile has an optional search parameter for clinicalStatus, but not verificationStatus, which can be problematic.  The implementation note (red text below) in the profile should be clarified since it is possible to have a NULL clinicalStatus when NOT entered in error (for diagnosis and health concerns).  Thus, if you want to get all possible active conditions (defined as non-resolved/non-error conditions including problems, diagnoses, and health concerns), then we need to include NULL clinical-status AND add another search parameter to exclude verificationStatus of entered-in-error.  Doing the search below is only guaranteed to return active problems. 

      Alternatively, clarify that the search below may exclude diagnoses and health concerns without a clinicalStatus specified.

      SHOULD support searching using the combination of the patient and clinical-status search parameters:

      GET [base]/Condition?patient={Type/}[id]&clinical-status=http://terminology.hl7.org/CodeSystem/condition-clinical|active,http://terminology.hl7.org/CodeSystem/condition-clinical|recurrance,http://terminology.hl7.org/CodeSystem/condition-clinical|remission

      Example:

      1. GET [base/Condition?patient=1032702&clinical-status=http://terminology.hl7.org/CodeSystem/condition-clinical|active,http://terminology.hl7.org/CodeSystem/condition-clinical|recurrance,http://terminology.hl7.org/CodeSystem/condition-clinical|remission

      Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and all "active" statuses (active,relapse,remission). This will not return any "entered in error" resources because of the conditional presence of the clinicalStatus element.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              michelle.m.miller Michelle Miller
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: