Indicates an actual or potential clinical issue with or between one or more active or proposed clinical actions for a patient; e.g. Drug-drug interaction, Ineffective treatment frequency, Procedure-condition conflict, gaps in care, etc.

Business identifiers assigned to this detected issue by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server.

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

Note: 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 current state of the detected issue.

A nominal state-transition diagram can be found in the (Event pattern documentation

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is.

Partitions the detected issue into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior.

Used for filtering what detected issues are retrieved and displayed.

Categorization might be done automatically (inferred by code) or manually by user assertion. The absence of a category may limit the ability to determine when the element should be handled, so strong consideration should be given to how systems will be able to determine category values for legacy data and how data that cannot be categorized will be handled. As well, some categories might not be mutually exclusive, so systems should prepare for multiple declared categories - even within a single category 'axis'. In general, there should not be a 'strong' binding ('required' or 'extensible') on the category element overall. Instead, the element can be sliced and bindings can be asserted that apply to particular repetitions.

A code that identifies the specific type of issue detected.

Indicates the degree of importance associated with the identified issue based on the potential impact on the patient.

Indicates the subject whose record the detected issue is associated with.

While the subject could be inferred by tracing the subject of the implicated resources, it's useful to have a direct link for query purposes.

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

Links the detected issue to the Encounter context. May also affect access control.

This will typically be the encounter the detected issue was created during, but some detected issues may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests).

The date, period or timing when the detected issue did occur or is occurring.

No-one can be responsible for mitigation prior to the issue being identified.

This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this {{event}} is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds. .

Individual or device responsible for the issue being raised. For example, a decision support application or a pharmacist conducting a medication review.

Indicates the resource representing the current activity or proposed activity that is potentially problematic.

There's an implicit constraint on the number of implicated resources based on DetectedIssue.type; e.g. For drug-drug, there would be more than one. For timing, there would typically only be one.

Supporting evidence or manifestations that provide the basis for identifying the detected issue such as a GuidanceResponse or MeasureReport.

A manifestation that led to the recording of this detected issue.

Links to resources that constitute evidence for the detected issue such as a GuidanceResponse or MeasureReport.

A textual explanation of the detected issue.

Should focus on information not covered elsewhere as discrete data - no need to duplicate the narrative.

The literature, knowledge-base or similar reference that describes the propensity for the detected issue identified.

Indicates an action that has been taken or is committed to reduce or eliminate the likelihood of the risk identified by the detected issue from manifesting. Can also reflect an observation of known mitigating factors that may reduce/eliminate the need for any action.

Describes the action that was taken or the observation that was made that reduces/eliminates the risk associated with the identified issue.

The "text" component can be used for detail or when no appropriate code exists.

Indicates when the mitigating action was documented.

This might not be the same as when the mitigating step was actually taken.

Identifies the practitioner who determined the mitigation and takes responsibility for the mitigation step occurring.

Clinicians may add additional notes or justifications about the mitigation action. For example, patient can have this drug because they have had it before without any issues. Multiple justifications may be provided.