A clinical condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern.

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.

Allows identification of the condition as it is known by various participating systems and in a way that remains consistent across servers.

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 clinical status of the condition.

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

The verification status to support the clinical status of the condition. The verification status pertains to the condition, itself, not to any specific condition attribute.

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.

A category assigned to the condition.

The categorization is often highly contextual and may appear poorly differentiated or not very useful in other contexts.

A subjective assessment of the severity of the condition as evaluated by the clinician.

Coding of the severity with a terminology is preferred, where possible.

Identification of the condition, problem or diagnosis.

0..1 to account for primarily narrative only resources.

The anatomical location where this condition manifests itself.

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.

Indicates the patient or group who the condition record is associated with.

Group is typically used for veterinary or public health use cases.

The Encounter during which this Condition was created or to which the creation of this record is tightly associated.

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".

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. Period is generally used to convey an imprecise onset that occurred within the time period. For example, Period is not intended to convey the transition period before the chronic bronchitis or COPD condition was diagnosed, but Period can be used to convey an imprecise diagnosis date.

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" - Some conditions, such as chronic 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.

The recordedDate represents when this particular Condition record was created in the system, which is often a system-generated date.

If the recordedDate is known via a sending system, it is preferred that the receiving system preserve the date. If the recorded date is not provided by the sending system, it is acceptable for the receiving system to assert their system-generated date.

Individual who recorded the record and takes responsibility for its content.

Individual or device that is making the condition statement.

A simple summary of the stage such as "Stage 3" or "Early Onset". The determination of the stage is disease-specific, such as cancer, retinopathy of prematurity, kidney diseases, Alzheimer's, or Parkinson disease.

A simple summary of the stage such as "Stage 3" or "Early Onset". The determination of the stage is disease-specific, such as cancer, retinopathy of prematurity, kidney diseases, Alzheimer's, or Parkinson disease.

Reference to a formal record of the evidence on which the staging assessment is based.

The kind of staging, such as pathological or clinical staging.

Supporting evidence / manifestations that are the basis of the Condition's verification status, such as evidence that confirmed or refuted the condition.

If the condition was confirmed, but subsequently refuted, then the evidence can be cumulative including all evidence over time. The evidence may be a simple list of coded symptoms/manifestations, or references to observations or formal assessments, or both.

A manifestation or symptom that led to the recording of this condition.

Links to other relevant information, including pathology reports.

Additional information about the Condition. This is a general notes/comments entry for description of the Condition, its diagnosis and prognosis.