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