Release 4

This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU) in it's permanent home (it will always be available at this URL). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

9.10 Resource DetectedIssue - Content

Clinical Decision Support Work GroupMaturity Level: 1 Trial UseSecurity Category: Patient Compartments: Device, Patient, Practitioner

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, etc.

This resource is an event resource from a FHIR workflow perspective - see Workflow, specifically Event.

This resource applies to various circumstances where there is a concern about an existing or proposed set of clinical activity. The issue could relate to single, proposed, or multiple actions. It does not apply to technical issues (e.g. lack of user permissions) but could relate to violation of patient consent limitations. Examples include:

  • Drug-drug interactions
  • Inappropriate therapy (wrong dose, frequency, body site)
  • Duplicate therapy

This resource represents a specific instance of a potential issue for a particular patient. It is not intended to represent general patient-independent knowledge. This resource is also not intended to be used in defining general prohibitions on actions such as "No NSAIDs", "No solid oral dose forms" or "No MRIs - metallic tattoos". These guidelines can be captured using the AllergyIntolerance, and/or Flag resources. Similarly, this resource is not to be used to capture clinical facts that may imply contraindications such as pregnancy, breast feeding, patient preferences, past procedures, etc. These would be represented using Condition, Procedure or other resources.

This resource only applies to documenting a risk associated with a specific planned or ongoing action, or the lack of an action which should be planned - not a general propensity to risk. The latter would be handled using AllergyIntolerance for substance-specific issues or Flag for other types of issues. In addition, the resource represents patient-specific and time-bound risk manifestations, not generic knowledge statements about risks that can exist.

This resource is limited to clinical issues associated with a proposed or ongoing action. It does not cover technical issues such as lack of permission, duplicate identifiers, insufficient data, and other business rule violations. Technical issues are conveyed using the OperationOutcome resource. It is possible to have both OperationOutcome and DetectedIssue together, where the OperationOutcome might indicate that a requested action was rejected due to a clinical issue and the DetectedIssue provides the details of the issue.

Detected issues are typically identified by decision support systems. However, they may also be captured directly by clinicians. The latter typically happens for one of two reasons:

  1. A clinician wishes to communicate an issue to another clinician whose responsibility would be to resolve it (e.g. a pharmacist identifying an issue with a prescription prior to putting it on hold)
  2. A clinician wishes to pre-emptively identify that an issue is known and is being managed (to avoid red flags being raised as part of downstream workflow); e.g. Submitting a new order and including a link to a "duplicate therapy" issue with mitigation indicating that the therapy is not considered to be duplicate.

Decision-support generated issues can result from calling a decision-support engine directly (e.g. via a custom OperationDefinition) or as part of an attempt to perform some other function (creating an order, submitting an insurance claim, capturing a medication list). When the issues are generated as a by-product of performing some other sort of action, they may be included in the "response" to the requested action in the same manner as an OperationOutcome. In fact, both may be present - the OperationOutcome indicating that there was a warning or error associated with the request and a DetectedIssue providing the clinical details. (The OperationOutcome could point to the DetectedIssue via an extension.)

In those circumstances where requested operations are rejected as a result of a detected issue, the workflow may support allowing the operation to be re-tried, provided that the identified issue is included as part of the submission (possibly also including a mitigation). In doing so, the sender acknowledges the issue and takes responsibility for it, thus allowing the requested operation to proceed. See Linking to Detected Issues for guidance on how a DetectedIssue instance might be included as part of another operation.

Systems that require such workflows should document expected behavior as part of their CapabilityStatement declarations.

This resource is referenced by MedicationDispense, MedicationKnowledge and MedicationRequest

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. DetectedIssue TUDomainResourceClinical issue with action
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierUnique id for the detected issue
... status ?!Σ1..1coderegistered | preliminary | final | amended +
ObservationStatus (Required)
... code Σ0..1CodeableConceptIssue Category, e.g. drug-drug, duplicate therapy, etc.
Detected Issue Category (Preferred)
... severity Σ0..1codehigh | moderate | low
DetectedIssueSeverity (Required)
... patient Σ0..1Reference(Patient)Associated patient
... identified[x] Σ0..1When identified
.... identifiedDateTimedateTime
.... identifiedPeriodPeriod
... author Σ0..1Reference(Practitioner | PractitionerRole | Device)The provider or device that identified the issue
... implicated Σ0..*Reference(Any)Problem resource
... evidence 0..*BackboneElementSupporting evidence
.... code 0..*CodeableConceptManifestation
Manifestation and Symptom Codes (Example)
.... detail 0..*Reference(Any)Supporting information
... detail 0..1stringDescription and context
... reference 0..1uriAuthority for issue
... mitigation 0..*BackboneElementStep taken to address
.... action 1..1CodeableConceptWhat mitigation?
Detected Issue Mitigation Action (Preferred)
.... date 0..1dateTimeDate committed
.... author 0..1Reference(Practitioner | PractitionerRole)Who is committing?

doco Documentation for this format

UML Diagram (Legend)

DetectedIssue (DomainResource)Business identifier associated with the detected issue recordidentifier : Identifier [0..*]Indicates the status of the detected issue (this element modifies the meaning of other elements)status : code [1..1] « Indicates the status of the identified issue. (Strength=Required)ObservationStatus! »Identifies the general type of issue identifiedcode : CodeableConcept [0..1] « Codes identifying the general type of detected issue; e.g. Drug-drug interaction, Timing issue, Duplicate therapy, etc. (Strength=Preferred)DetectedIssueCategory? »Indicates the degree of importance associated with the identified issue based on the potential impact on the patientseverity : code [0..1] « Indicates the potential degree of impact of the identified issue on the patient. (Strength=Required)DetectedIssueSeverity! »Indicates the patient whose record the detected issue is associated withpatient : Reference [0..1] « Patient »The date or period when the detected issue was initially identifiedidentified[x] : Type [0..1] « dateTime|Period »Individual or device responsible for the issue being raised. For example, a decision support application or a pharmacist conducting a medication reviewauthor : Reference [0..1] « Practitioner|PractitionerRole|Device »Indicates the resource representing the current activity or proposed activity that is potentially problematicimplicated : Reference [0..*] « Any »A textual explanation of the detected issuedetail : string [0..1]The literature, knowledge-base or similar reference that describes the propensity for the detected issue identifiedreference : uri [0..1]EvidenceA manifestation that led to the recording of this detected issuecode : CodeableConcept [0..*] « Codes that describes the types of evidence for a detected issue. (Strength=Example)ManifestationAndSymptomCodes?? »Links to resources that constitute evidence for the detected issue such as a GuidanceResponse or MeasureReportdetail : Reference [0..*] « Any »MitigationDescribes the action that was taken or the observation that was made that reduces/eliminates the risk associated with the identified issueaction : CodeableConcept [1..1] « Codes describing steps taken to resolve the issue or other circumstances that mitigate the risk associated with the issue; e.g. 'added concurrent therapy', 'prior therapy documented', etc. (Strength=Preferred)DetectedIssueMitigationAction? »Indicates when the mitigating action was documenteddate : dateTime [0..1]Identifies the practitioner who determined the mitigation and takes responsibility for the mitigation step occurringauthor : Reference [0..1] « Practitioner|PractitionerRole »Supporting evidence or manifestations that provide the basis for identifying the detected issue such as a GuidanceResponse or MeasureReportevidence[0..*]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 actionmitigation[0..*]

XML Template

<DetectedIssue xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Unique id for the detected issue --></identifier>
 <status value="[code]"/><!-- 1..1 registered | preliminary | final | amended + -->
 <code><!-- 0..1 CodeableConcept Issue Category, e.g. drug-drug, duplicate therapy, etc. --></code>
 <severity value="[code]"/><!-- 0..1 high | moderate | low -->
 <patient><!-- 0..1 Reference(Patient) Associated patient --></patient>
 <identified[x]><!-- 0..1 dateTime|Period When identified --></identified[x]>
 <author><!-- 0..1 Reference(Practitioner|PractitionerRole|Device) The provider or device that identified the issue --></author>
 <implicated><!-- 0..* Reference(Any) Problem resource --></implicated>
 <evidence>  <!-- 0..* Supporting evidence -->
  <code><!-- 0..* CodeableConcept Manifestation --></code>
  <detail><!-- 0..* Reference(Any) Supporting information --></detail>
 </evidence>
 <detail value="[string]"/><!-- 0..1 Description and context -->
 <reference value="[uri]"/><!-- 0..1 Authority for issue -->
 <mitigation>  <!-- 0..* Step taken to address -->
  <action><!-- 1..1 CodeableConcept What mitigation? --></action>
  <date value="[dateTime]"/><!-- 0..1 Date committed -->
  <author><!-- 0..1 Reference(Practitioner|PractitionerRole) Who is committing? --></author>
 </mitigation>
</DetectedIssue>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:DetectedIssue;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:DetectedIssue.identifier [ Identifier ], ... ; # 0..* Unique id for the detected issue
  fhir:DetectedIssue.status [ code ]; # 1..1 registered | preliminary | final | amended +
  fhir:DetectedIssue.code [ CodeableConcept ]; # 0..1 Issue Category, e.g. drug-drug, duplicate therapy, etc.
  fhir:DetectedIssue.severity [ code ]; # 0..1 high | moderate | low
  fhir:DetectedIssue.patient [ Reference(Patient) ]; # 0..1 Associated patient
  # DetectedIssue.identified[x] : 0..1 When identified. One of these 2
    fhir:DetectedIssue.identifiedDateTime [ dateTime ]
    fhir:DetectedIssue.identifiedPeriod [ Period ]
  fhir:DetectedIssue.author [ Reference(Practitioner|PractitionerRole|Device) ]; # 0..1 The provider or device that identified the issue
  fhir:DetectedIssue.implicated [ Reference(Any) ], ... ; # 0..* Problem resource
  fhir:DetectedIssue.evidence [ # 0..* Supporting evidence
    fhir:DetectedIssue.evidence.code [ CodeableConcept ], ... ; # 0..* Manifestation
    fhir:DetectedIssue.evidence.detail [ Reference(Any) ], ... ; # 0..* Supporting information
  ], ...;
  fhir:DetectedIssue.detail [ string ]; # 0..1 Description and context
  fhir:DetectedIssue.reference [ uri ]; # 0..1 Authority for issue
  fhir:DetectedIssue.mitigation [ # 0..* Step taken to address
    fhir:DetectedIssue.mitigation.action [ CodeableConcept ]; # 1..1 What mitigation?
    fhir:DetectedIssue.mitigation.date [ dateTime ]; # 0..1 Date committed
    fhir:DetectedIssue.mitigation.author [ Reference(Practitioner|PractitionerRole) ]; # 0..1 Who is committing?
  ], ...;
]

Changes since R3

DetectedIssue
DetectedIssue.identifier
  • Max Cardinality changed from 1 to *
DetectedIssue.status
  • Change value set from http://hl7.org/fhir/ValueSet/observation-status to http://hl7.org/fhir/ValueSet/observation-status|4.0.1
DetectedIssue.code
  • Renamed from category to code
DetectedIssue.severity
  • Change value set from http://hl7.org/fhir/ValueSet/detectedissue-severity to http://hl7.org/fhir/ValueSet/detectedissue-severity|4.0.1
DetectedIssue.identified[x]
  • Added Element
DetectedIssue.author
  • Type Reference: Added Target Type PractitionerRole
DetectedIssue.evidence
  • Added Element
DetectedIssue.evidence.code
  • Added Element
DetectedIssue.evidence.detail
  • Added Element
DetectedIssue.mitigation.author
  • Type Reference: Added Target Type PractitionerRole
DetectedIssue.date
  • deleted

See the Full Difference for further information

This analysis is available as XML or JSON.

See R3 <--> R4 Conversion Maps (status = 4 tests that all execute ok. All tests pass round-trip testing and all r3 resources are valid.)

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. DetectedIssue TUDomainResourceClinical issue with action
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierUnique id for the detected issue
... status ?!Σ1..1coderegistered | preliminary | final | amended +
ObservationStatus (Required)
... code Σ0..1CodeableConceptIssue Category, e.g. drug-drug, duplicate therapy, etc.
Detected Issue Category (Preferred)
... severity Σ0..1codehigh | moderate | low
DetectedIssueSeverity (Required)
... patient Σ0..1Reference(Patient)Associated patient
... identified[x] Σ0..1When identified
.... identifiedDateTimedateTime
.... identifiedPeriodPeriod
... author Σ0..1Reference(Practitioner | PractitionerRole | Device)The provider or device that identified the issue
... implicated Σ0..*Reference(Any)Problem resource
... evidence 0..*BackboneElementSupporting evidence
.... code 0..*CodeableConceptManifestation
Manifestation and Symptom Codes (Example)
.... detail 0..*Reference(Any)Supporting information
... detail 0..1stringDescription and context
... reference 0..1uriAuthority for issue
... mitigation 0..*BackboneElementStep taken to address
.... action 1..1CodeableConceptWhat mitigation?
Detected Issue Mitigation Action (Preferred)
.... date 0..1dateTimeDate committed
.... author 0..1Reference(Practitioner | PractitionerRole)Who is committing?

doco Documentation for this format

UML Diagram (Legend)

DetectedIssue (DomainResource)Business identifier associated with the detected issue recordidentifier : Identifier [0..*]Indicates the status of the detected issue (this element modifies the meaning of other elements)status : code [1..1] « Indicates the status of the identified issue. (Strength=Required)ObservationStatus! »Identifies the general type of issue identifiedcode : CodeableConcept [0..1] « Codes identifying the general type of detected issue; e.g. Drug-drug interaction, Timing issue, Duplicate therapy, etc. (Strength=Preferred)DetectedIssueCategory? »Indicates the degree of importance associated with the identified issue based on the potential impact on the patientseverity : code [0..1] « Indicates the potential degree of impact of the identified issue on the patient. (Strength=Required)DetectedIssueSeverity! »Indicates the patient whose record the detected issue is associated withpatient : Reference [0..1] « Patient »The date or period when the detected issue was initially identifiedidentified[x] : Type [0..1] « dateTime|Period »Individual or device responsible for the issue being raised. For example, a decision support application or a pharmacist conducting a medication reviewauthor : Reference [0..1] « Practitioner|PractitionerRole|Device »Indicates the resource representing the current activity or proposed activity that is potentially problematicimplicated : Reference [0..*] « Any »A textual explanation of the detected issuedetail : string [0..1]The literature, knowledge-base or similar reference that describes the propensity for the detected issue identifiedreference : uri [0..1]EvidenceA manifestation that led to the recording of this detected issuecode : CodeableConcept [0..*] « Codes that describes the types of evidence for a detected issue. (Strength=Example)ManifestationAndSymptomCodes?? »Links to resources that constitute evidence for the detected issue such as a GuidanceResponse or MeasureReportdetail : Reference [0..*] « Any »MitigationDescribes the action that was taken or the observation that was made that reduces/eliminates the risk associated with the identified issueaction : CodeableConcept [1..1] « Codes describing steps taken to resolve the issue or other circumstances that mitigate the risk associated with the issue; e.g. 'added concurrent therapy', 'prior therapy documented', etc. (Strength=Preferred)DetectedIssueMitigationAction? »Indicates when the mitigating action was documenteddate : dateTime [0..1]Identifies the practitioner who determined the mitigation and takes responsibility for the mitigation step occurringauthor : Reference [0..1] « Practitioner|PractitionerRole »Supporting evidence or manifestations that provide the basis for identifying the detected issue such as a GuidanceResponse or MeasureReportevidence[0..*]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 actionmitigation[0..*]

XML Template

<DetectedIssue xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Unique id for the detected issue --></identifier>
 <status value="[code]"/><!-- 1..1 registered | preliminary | final | amended + -->
 <code><!-- 0..1 CodeableConcept Issue Category, e.g. drug-drug, duplicate therapy, etc. --></code>
 <severity value="[code]"/><!-- 0..1 high | moderate | low -->
 <patient><!-- 0..1 Reference(Patient) Associated patient --></patient>
 <identified[x]><!-- 0..1 dateTime|Period When identified --></identified[x]>
 <author><!-- 0..1 Reference(Practitioner|PractitionerRole|Device) The provider or device that identified the issue --></author>
 <implicated><!-- 0..* Reference(Any) Problem resource --></implicated>
 <evidence>  <!-- 0..* Supporting evidence -->
  <code><!-- 0..* CodeableConcept Manifestation --></code>
  <detail><!-- 0..* Reference(Any) Supporting information --></detail>
 </evidence>
 <detail value="[string]"/><!-- 0..1 Description and context -->
 <reference value="[uri]"/><!-- 0..1 Authority for issue -->
 <mitigation>  <!-- 0..* Step taken to address -->
  <action><!-- 1..1 CodeableConcept What mitigation? --></action>
  <date value="[dateTime]"/><!-- 0..1 Date committed -->
  <author><!-- 0..1 Reference(Practitioner|PractitionerRole) Who is committing? --></author>
 </mitigation>
</DetectedIssue>

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:DetectedIssue;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:DetectedIssue.identifier [ Identifier ], ... ; # 0..* Unique id for the detected issue
  fhir:DetectedIssue.status [ code ]; # 1..1 registered | preliminary | final | amended +
  fhir:DetectedIssue.code [ CodeableConcept ]; # 0..1 Issue Category, e.g. drug-drug, duplicate therapy, etc.
  fhir:DetectedIssue.severity [ code ]; # 0..1 high | moderate | low
  fhir:DetectedIssue.patient [ Reference(Patient) ]; # 0..1 Associated patient
  # DetectedIssue.identified[x] : 0..1 When identified. One of these 2
    fhir:DetectedIssue.identifiedDateTime [ dateTime ]
    fhir:DetectedIssue.identifiedPeriod [ Period ]
  fhir:DetectedIssue.author [ Reference(Practitioner|PractitionerRole|Device) ]; # 0..1 The provider or device that identified the issue
  fhir:DetectedIssue.implicated [ Reference(Any) ], ... ; # 0..* Problem resource
  fhir:DetectedIssue.evidence [ # 0..* Supporting evidence
    fhir:DetectedIssue.evidence.code [ CodeableConcept ], ... ; # 0..* Manifestation
    fhir:DetectedIssue.evidence.detail [ Reference(Any) ], ... ; # 0..* Supporting information
  ], ...;
  fhir:DetectedIssue.detail [ string ]; # 0..1 Description and context
  fhir:DetectedIssue.reference [ uri ]; # 0..1 Authority for issue
  fhir:DetectedIssue.mitigation [ # 0..* Step taken to address
    fhir:DetectedIssue.mitigation.action [ CodeableConcept ]; # 1..1 What mitigation?
    fhir:DetectedIssue.mitigation.date [ dateTime ]; # 0..1 Date committed
    fhir:DetectedIssue.mitigation.author [ Reference(Practitioner|PractitionerRole) ]; # 0..1 Who is committing?
  ], ...;
]

Changes since Release 3

DetectedIssue
DetectedIssue.identifier
  • Max Cardinality changed from 1 to *
DetectedIssue.status
  • Change value set from http://hl7.org/fhir/ValueSet/observation-status to http://hl7.org/fhir/ValueSet/observation-status|4.0.1
DetectedIssue.code
  • Renamed from category to code
DetectedIssue.severity
  • Change value set from http://hl7.org/fhir/ValueSet/detectedissue-severity to http://hl7.org/fhir/ValueSet/detectedissue-severity|4.0.1
DetectedIssue.identified[x]
  • Added Element
DetectedIssue.author
  • Type Reference: Added Target Type PractitionerRole
DetectedIssue.evidence
  • Added Element
DetectedIssue.evidence.code
  • Added Element
DetectedIssue.evidence.detail
  • Added Element
DetectedIssue.mitigation.author
  • Type Reference: Added Target Type PractitionerRole
DetectedIssue.date
  • deleted

See the Full Difference for further information

This analysis is available as XML or JSON.

See R3 <--> R4 Conversion Maps (status = 4 tests that all execute ok. All tests pass round-trip testing and all r3 resources are valid.)

 

See the Profiles & Extensions and the alternate definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions & the dependency analysis

PathDefinitionTypeReference
DetectedIssue.status Indicates the status of the identified issue.RequiredObservationStatus
DetectedIssue.code Codes identifying the general type of detected issue; e.g. Drug-drug interaction, Timing issue, Duplicate therapy, etc.PreferredDetectedIssueCategory
DetectedIssue.severity Indicates the potential degree of impact of the identified issue on the patient.RequiredDetectedIssueSeverity
DetectedIssue.evidence.code Codes that describes the types of evidence for a detected issue.ExampleManifestationAndSymptomCodes
DetectedIssue.mitigation.action Codes describing steps taken to resolve the issue or other circumstances that mitigate the risk associated with the issue; e.g. 'added concurrent therapy', 'prior therapy documented', etc.PreferredDetectedIssueMitigationAction

DetectedIssue follows the pattern of linking from the resource created "second". As DetectedIssue originates in response to one or more other existing records, it points to those records rather than being pointed to from them.

In some cases, a detected issue might be associated with a single record. When this occurs, it may be stored as a contained resource within the implicated resource provided that there is no expected need to search for the detected issue directly. However, with detected issues that implicate multiple records, containment is more problematic. In some workflows, a detected issue might be deemed to be "owned" by the record whose creation triggers the contraindication being created - i.e. the "second" or "last" record. However, where multiple actions are proposed as part of a single submission, there can be no single owner and containment will not be feasible.

If there is a strong need to point from an implicated resource to DetectedIssue and containment is not appropriate, an extension can be used.

DetectedIssue is a resource that is frequently associated with workflow challenges where frequent alerts that are not clinically relevant result in clinicians tuning out (or turning off) the content and thus missing relevant alerts. Give consideration to this issue before making heavy use of this resource.

  • Are author, reference and/or mitigation (and its various parts) all part of the 80%?

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

NameTypeDescriptionExpressionIn Common
authorreferenceThe provider or device that identified the issueDetectedIssue.author
(Practitioner, Device, PractitionerRole)
codetokenIssue Category, e.g. drug-drug, duplicate therapy, etc.DetectedIssue.code
identifieddateWhen identifiedDetectedIssue.identified
identifiertokenUnique id for the detected issueDetectedIssue.identifier30 Resources
implicatedreferenceProblem resourceDetectedIssue.implicated
(Any)
patientreferenceAssociated patientDetectedIssue.patient
(Patient)
33 Resources