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

This records Business identifiers associated with assigned to this condition that are defined by business processes and/or used to refer to it when a direct URL reference to the performer or other systems which remain constant as the resource itself is not appropriate (e.g. in CDA documents, or in written / printed documentation). updated and propagates from server to server.

Need to allow connection to Allows identification of the condition as it is known by various participating systems and in a wider workflow. 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.

This element It is labeled as a modifier because the status contains codes possible that mark the condition as not currently valid well-controlled or of concern. poorly-controlled clinical status could alternatively be conveyed via a pre-coordinated Condition.code.

The verification status to support the clinical status of the condition.

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.

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 body-site-instance body-structure . 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.

Encounter during which the condition was first asserted.

This record indicates the encounter this particular record is associated with. In the case of a "new" "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". "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.

The date or estimated date that the condition resolved or went into remission. This is called "abatement" "abatement" because of the many overloaded connotations associated with "remission" "remission" or "resolution" "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.

The date on which the existance existence of the Condition was first asserted or acknowledged.

The assertedDate represents the date when this particular Condition record was created in the EHR, not the date of the most recent update in terms of when severity, abatement, etc. were specified.  The date of the last record modification can be retrieved from the resource metadata.

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

Individual who is making the condition statement.

Clinical stage or grade of a condition. May include formal severity assessments.

A simple summary of the stage such as "Stage 3". "Stage 3". The determination of the stage is disease-specific.

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 evidence / manifestations that are the basis on which this condition is suspected of the Condition's verification status, such as evidence that confirmed or confirmed. refuted the condition.

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.