This records identifiers associated with this condition that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate (e.g. in CDA documents, or in written / printed documentation).

Need to allow connection to a wider workflow.

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.

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.

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.

The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured. and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.

Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.

Indicates that this coding was chosen by a user directly - i.e. off a pick list of available items (codes or displays).

This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.

Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.

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. May be a summary code, or a reference to a very precise definition of the location, or both.

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" diagnosis reflecting ongoing/revised information about the condition, this might be distinct from the first encounter in which the underlying condition was first "known".

The date on which the existance 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 is making the condition statement.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

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

For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. Annotations SHOULD NOT be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).