Condition

Definition

A condition is an Observation about the patient or

Types of Conditions

Previous discussions have been principally focused on specific uses of a Condition, rather than the general concept of the Condition itself. The concept of a Condition has broadened as new use cases are examined which use the Clinical Statement.

Disorder

This is the prototypical Condition. It is an instance of an Observation Event, typically with a healthcare provider as author. If active, these provide a good deal of the content for a Problem List, which is a dynamically generated list of active Health Concerns (or perhaps their naming Conditions?) based on specific criteria. There is no restriction that it must be a disease (or the concept of disease could be expanded to include a wide range of abnormal situation). Family and social issues would be represented using the disorder model. In addition, it need not be an identified disease. It could be a sign, symptoms, or abnormal screening or diagnostic study. There is also no reason why a patient, cannot create a new disorder-type Health Concern.

It typically, but not always, represents some identified disease process in a patient. The Disorder need not be in the record target. For example, the subject may be a fetus in utero. It could be a family member with some health related (including psychosocial issues) problem which impacts the patient (record target), e.g. pertussis in the the sibling of an infant. (In all likelihood this would include the disorder with the sibling as the subject, and a 'risk for pertussis would be a related naming condition. [see below])

There is an identified need to be able to specify the clinical status of a condition. This is distinct from the status of any model element in an EHRS (i.e. Condition.statusCode isn't used for this).

In prior discussions, there was a need to name the reason for some health care action. Names suggested included: - Problem - CareIndication - CareActivityIndication - CareActivityReason - CareProvisionReason - ClinicalFinding - ClinicalAssertion - Condition - ClinicalCondition - HealthIssue - HealthState

To this one might add 'Diagnosis'.

This can include specific items such as the Chief Complaint, Presenting Problem, but not the Reason for Visit. These have been defined [ref]. The Chief Complaint is the narrative account of what a patient stated (or perhaps even entered themselves) as the symptoms or other disorder related aspects. It may include translations. An encounter will have [0..*] chief complaints. Some encounters are specifically based on a healthcare process (i.e. some procedure) in a patient without any complaints. E.g. immunization of a healthy patient or medical clearance for incarceration/jail. These procedures are the Reason for Visit and would not be maintained as part of a Health Concern, as they are part of a Care Plan. They typically will have another Condition as the reason.

Once a disorder has resolved, it is still maintained as a Health Concern. The information regarding it remains the same. However, conditions with a clinical status of "resolved" would likely appear in the generation of a Past Medical History

Risk

One type of Conditions, very similar to disorders, is an assertion that the subject (patient, fetus, family, etc.) is at risk for some specified undesirable stat (Observation Risk). This is not an assertion of a risk factor (these typically are disorders), but it likely will have associations (interpretation) with risk factors which support the determination of some risk.

Future systems may in fact have hundreds, if not thousands, of risks which are tracked and quantified. One can envision a design where a system instantiates a list of risks faced by every person (likely customized by a clinical decision support system, and hopefully quantified, when possible) simply by nature of being born, e.g. risk of traumatic brain injury, risk of pneumonia, risk of diabetes, risk of meningitis, risk of athlete's foot, risk of malaria, risk of child abuse, risk of fatal or disabling motor vehicle collision, etc. etc In practicality, implementer would likely limit the risks to those which will have some sort of associated Care Plan.

E.g. there is considerable attention paid in childhood to educating the child and parents, as well as adolescent and adults, about measures to mitigate risks, e.g. use of helmet whenever the child is on a bike, skates, or using any other self-propelled wheeled device; immunization against HiB, pneumococcus and meningococcus; keeping patient active and on a healthy diet; initiation of malaria prophylaxis based on individuals travel plans (or seasons when EHRS is used in endemic regions); discussions on parenting skills, education on risks associated with shaken baby, and assessment for maternal depression or significant stressors in any adult caring for an infant; and counseling patient on use of proper restraints in motor vehicles. While human clinicians may have difficulty navigating hundreds to thousands of risks, an EHRS could be designed to automate the monitoring of these, capture needed data (from patient record, public health reports, etc.) and maintain vigilance. If the risk of some disorder reaches some threshold (likely based on the severity of the disorder as well as the probability) it could be surfaced in a problem list by the EHRS software.

The actual value of a Risk would be expressed as a probabilistic or uncertain range. Even if the probability isn't known, or is only approximate (e.g. low v. high), then terminology can help specify the qualification.