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 identifier associated with the identifiers assigned to this detected issue record. by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server.

Allows linking instances identification of the same detected issue found on different 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.

Indicates the status The current state of the detected issue.

This element is labeled as a modifier because A nominal state-transition diagram can be found in the status contains (Event pattern documentation

Unknown does not represent "other" - one of the codes cancelled and entered-in-error that mark defined statuses must apply. Unknown is used when the issue as authoring system is not currently valid. sure what the current status is. Processing error is used to indicate that an error occurred attempting to evaluate a detected issue. For example, a DetectedIssue with a code of drug-drug interaction could have a status of processing-error to indicate that an error was encountered attempting to determine whether there was a drug-drug interaction.

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.

Identifies 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 general 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 identified. detected.

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

Indicates the patient 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 date, period or date-time timing when the detected issue was initially identified. 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.

The quality of the evidence supporting identification of the detected issue. The code system used specifies the quality scale used to grade this evidence source while the code specifies the actual quality score (represented as a coded value) associated with the evidence.

The time frame in which the clinical effects of the detected issue may be expected to occur. Rapid refers to an expected onset within 24 hours. Delayed refers to an expected onset in more than 24 hours.

Represents the medication class that is responsible for the detected issue.

For example, for a duplicate therapy or an alergy alert, this class would represent the medication class to which the medications belong.

An indication of the importance or type of step that should or may be taken in order to address the detected issue. This is different than mitigation in that it is not specifically providing actions to be taken, rather general suggestions about approach.

Indicates an action that has been taken or is committed to 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" "text" component can be used for detail or when no appropriate code exists.

Indicates when the mitigating action was documented.

This may 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.