This page is part of the FHIR Specification (v4.3.0: R4B - STU). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5R4BR4R3R2
con-3Guideline Condition.clinicalStatus SHOULD be present if verificationStatus is not entered-in-error and category is problem-list-item verificationStatus.empty().not() and verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status' and code='entered-in-error').exists().not() and category.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-category' and code='problem-list-item').exists() implies clinicalStatus.empty().not() This is (only) a best practice guideline because:
Most systems will expect a clinicalStatus to be valued for problem-list-items that are managed over time, but might not need a clinicalStatus for point in time encounter-diagnosis.
con-4Rule If condition is abated, then clinicalStatus must be either inactive, resolved, or remission abatement.empty() or clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical' and (code='resolved' or code='remission' or code='inactive')).exists()
con-5Rule Condition.clinicalStatus SHALL NOT be present if verification Status is entered-in-error verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status' and code='entered-in-error').empty() or clinicalStatus.empty()
Condition.identifier
Element Id Condition.identifier
Definition
Business identifiers assigned to this condition by the performer or other systems which remain constant as the resource is updated and propagates from server to server.
Note This is a business identifier, not a resource identifier (see discussion)
This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.
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.
Invariants
Affect this element
con-3Guideline Condition.clinicalStatus SHOULD be present if verificationStatus is not entered-in-error and category is problem-list-item verificationStatus.empty().not() and verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status' and code='entered-in-error').exists().not() and category.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-category' and code='problem-list-item').exists() implies clinicalStatus.empty().not() This is (only) a best practice guideline because:
Most systems will expect a clinicalStatus to be valued for problem-list-items that are managed over time, but might not need a clinicalStatus for point in time encounter-diagnosis.
con-4Rule If condition is abated, then clinicalStatus must be either inactive, resolved, or remission abatement.empty() or clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical' and (code='resolved' or code='remission' or code='inactive')).exists()
con-5Rule Condition.clinicalStatus SHALL NOT be present if verification Status is entered-in-error verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status' and code='entered-in-error').empty() or clinicalStatus.empty()
Condition.verificationStatus
Element Id Condition.verificationStatus
Definition
The verification status to support the clinical status of the condition.
Is Modifier true (Reason: This element is labeled as a modifier because the status contains the code refuted and entered-in-error that mark the Condition as not currently valid.)
verificationStatus is not required. For example, when a patient has abdominal pain in the ED, there is not likely going to be a verification status.
The data type is CodeableConcept because verificationStatus 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.
Invariants
Affect this element
con-3Guideline Condition.clinicalStatus SHOULD be present if verificationStatus is not entered-in-error and category is problem-list-item verificationStatus.empty().not() and verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status' and code='entered-in-error').exists().not() and category.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-category' and code='problem-list-item').exists() implies clinicalStatus.empty().not() This is (only) a best practice guideline because:
Most systems will expect a clinicalStatus to be valued for problem-list-items that are managed over time, but might not need a clinicalStatus for point in time encounter-diagnosis.
con-5Rule Condition.clinicalStatus SHALL NOT be present if verification Status is entered-in-error verificationStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-ver-status' and code='entered-in-error').empty() or clinicalStatus.empty()
Only used if not implicit in code found in Condition.code. If the use case requires attributes from the BodySite resource (e.g. to identify and track separately) then use the standard extension bodySite. May be a summary code, or a reference to a very precise definition of the location, or both.
Condition.subject
Element Id Condition.subject
Definition
Indicates the patient or group who the condition record is associated with.
This will typically be the encounter the event occurred within, but some activities may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter. This record indicates the encounter this particular record is associated with. In the case of a "new" diagnosis reflecting ongoing/revised information about the condition, this might be distinct from the first encounter in which the underlying condition was first "known".
Condition.onset[x]
Element Id Condition.onset[x]
Definition
Estimated or actual date or date-time the condition began, in the opinion of the clinician.
Age is generally used when the patient reports an age at which the Condition began to occur.
Condition.abatement[x]
Element Id Condition.abatement[x]
Definition
The date or estimated date that the condition resolved or went into remission. This is called "abatement" because of the many overloaded connotations associated with "remission" or "resolution" - Conditions are never really resolved, but they can abate.
There is no explicit distinction between resolution and remission because in many cases the distinction is not clear. Age is generally used when the patient reports an age at which the Condition abated. If there is no abatement element, it is unknown whether the condition has resolved or entered remission; applications and users should generally assume that the condition is still valid. When abatementString exists, it implies the condition is abated.
Invariants
Affect this element
con-4Rule If condition is abated, then clinicalStatus must be either inactive, resolved, or remission abatement.empty() or clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical' and (code='resolved' or code='remission' or code='inactive')).exists()
Condition.recordedDate
Element Id Condition.recordedDate
Definition
The recordedDate represents when this particular Condition record was created in the system, which is often a system-generated date.
Supporting evidence / manifestations that are the basis of the Condition's verification status, such as evidence that confirmed or refuted the condition.