DetectedIssue
Introduction
Scope and Usage
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
- Gaps in care
This resource represents a specific instance of a potential issue for a particular patient. It is not intended to represent general patient-independent knowledge, the ClinicalUseDefinition resource is defined for that purpose. 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, AdverseEvent 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. The DetectedIssue resource is not intended to be used to capture alerts from devices such as heart monitors.
Boundaries and Relationships
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.
When author is a Device in a DetectedIssue, this typically represents the software service that supplied the detected issue as part of a clinical decision support request and response, as opposed to an alert from a monitoring device. The DeviceAlert resource should be used for that use case.
Background and Context
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:
- 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)
- 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.
Notes
Linking to Detected Issues
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.
Workflow Challenges
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.
Open Issues
- Are author, reference and/or mitigation (and its various parts) all part of the 80%?
StructureDefinition
Elements (Simplified)
- DetectedIssue [0..*]: - Clinical issue with action
- DetectedIssue.identifier [0..*]: Identifier Business identifier for detected issue
- DetectedIssue.status [1..1]: code required:detectedissue-status preliminary | final | entered-in-error | unknown | mitigated | processing-error
- DetectedIssue.category [0..*]: CodeableConcept preferred:detectedissue-category High level categorization of detected issue
- DetectedIssue.code [0..1]: CodeableConcept preferred:detectedissue-code Specific type of detected issue, e.g. drug-drug, duplicate therapy, etc
- DetectedIssue.severity [0..1]: CodeableConcept preferred:detectedissue-severity high | moderate | low
- DetectedIssue.subject [0..1]: [Reference(Patient](/Reference(Patient), Group, Device, Location, Organization, Procedure, Practitioner, Medication, Substance, BiologicallyDerivedProduct, NutritionProduct)) Associated subject
- DetectedIssue.encounter [0..1]: Reference(Encounter) Encounter the detected issue is part of
- DetectedIssue.identified[x] [0..1]: dateTime, Period, Timing When detected issue occurred/is occurring
- DetectedIssue.author [0..1]: [Reference(Patient](/Reference(Patient), RelatedPerson, Practitioner, PractitionerRole, Device)) The provider or device that identified the issue
- DetectedIssue.implicated [0..*]: Reference(Resource) Problem resource
- DetectedIssue.evidence [0..*]: BackboneElement Supporting evidence
- DetectedIssue.evidence.code [0..*]: CodeableConcept example:manifestation-or-symptom Manifestation
- DetectedIssue.evidence.detail [0..*]: Reference(Resource) Supporting information
- DetectedIssue.detail [0..1]: markdown Description and context
- DetectedIssue.reference [0..1]: uri Authority for issue
- DetectedIssue.qualityOfEvidence [0..1]: CodeableConcept example:evidence-quality The quality of the evidence supporting the detected issue
- DetectedIssue.expectedOnsetType [0..1]: CodeableConcept example:detectedissue-expected-onset-type Time frame of clinical effect
- DetectedIssue.medicationClass [0..*]: CodeableConcept example:detectedissue-example-medication-class What medication class
- DetectedIssue.managementCode [0..1]: CodeableConcept example:detectedissue-management-code Importance of taking action on the issue
- DetectedIssue.mitigation [0..*]: BackboneElement Step taken to address
- DetectedIssue.mitigation.action [1..1]: CodeableConcept preferred:detectedissue-mitigation-action What mitigation?
- DetectedIssue.mitigation.date [0..1]: dateTime Date committed
- DetectedIssue.mitigation.author [0..1]: [Reference(Practitioner](/Reference(Practitioner), PractitionerRole)) Who is committing?
- DetectedIssue.mitigation.note [0..*]: Annotation Additional notes about the mitigation
Mappings
- DetectedIssue Mappings — 54 mapping entries
Resource Packs
list-DetectedIssue-packs.xml
<?xml version="1.0" encoding="UTF-8"?>
<List xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../publish/List.xsd">
<id value="DetectedIssue-packs"/>
<status value="current"/>
<mode value="working"/>
</List>
Search Parameters
- author — reference — The provider or device that identified the issue —
DetectedIssue.author - category — token — Issue Category, e.g. drug-drug, duplicate therapy, etc. —
DetectedIssue.category - code — token — Issue Type, e.g. drug-drug, duplicate therapy, etc. —
DetectedIssue.code - identified — date — When identified —
DetectedIssue.identified.ofType(dateTime) | DetectedIssue.identified.ofType(Period) - identifier — token — Unique id for the detected issue —
DetectedIssue.identifier - implicated — reference — Problem resource —
DetectedIssue.implicated - subject — reference — Associated subject —
DetectedIssue.subject - patient — reference — Associated patient —
DetectedIssue.subject.where(resolve() is Patient) - status — token — The status of the issue —
DetectedIssue.status
Examples
- allergy — detectedissue-example-allergy — Patient is allergic to an inactive ingredient in an ordered medication
- ddi — detectedissue-example — Drug-drug interaction between prescription and medication statement
- detectedissue-example — detectedissue-example
- detectedissue-example-allergy — detectedissue-example-allergy
- detectedissue-example-dup — detectedissue-example-dup
- detectedissue-example-lab — detectedissue-example-lab
- detectedissue-examples-header — detectedissue-examples-header
- duplicate — detectedissue-example-dup — Diagnostic order is placed when a recent image of the same body site already exists
- lab — detectedissue-example-lab — Lab order is contraindicated based on a patient's existing medication
Mapping Exceptions
detectedissue-event-mapping-exceptions.xml
Divergent Elements
- Event.status → DetectedIssue.status
- shortUnmatched | reason=Unknown | pattern=preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown | resource=preliminary | final | entered-in-error | unknown | mitigated | processing-error
- Event.category → DetectedIssue.category
- Event.code → DetectedIssue.code
- shortUnmatched | reason=Specialization | pattern=What service was done | resource=Specific type of detected issue, e.g. drug-drug, duplicate therapy, etc
- definitionUnmatched | reason=Specialization | pattern=A code that identifies the specific service or action that was or is being performed. | resource=A code that identifies the specific type of issue detected.
- Event.subject → DetectedIssue.subject
- extraTypes | reason=Generalization
- shortUnmatched | reason=Specialization | pattern=Individual service was done for/to | resource=Associated subject
- definitionUnmatched | reason=Specialization | pattern=The individual or set of individuals the action is being or was performed on. | resource=Indicates the subject whose record the detected issue is associated with.
- requirementsUnmatched | reason=Specialization | pattern=Links the detected issue to the Patient context. May also affect access control. | resource=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.
- Event.performer.actor → DetectedIssue.author
- missingTypes | reason=Unknown | pattern=Reference(Organization, CareTeam)
- shortUnmatched | reason=Specialization | pattern=Who performed detected issue | resource=The provider or device that identified the issue
- definitionUnmatched | reason=Specialization | pattern=Indicates who or what performed the detected issue. | resource=Individual or device responsible for the issue being raised. For example, a decision support application or a pharmacist conducting a medication review.
- Event.reason → DetectedIssue.implicated
- missingTypes | reason=Unknown | pattern=CodeableReference(Condition, Observation, DiagnosticReport, DocumentReference)
- extraTypes | reason=Generalization
- shortUnmatched | reason=Specialization | pattern=Why was detected issue performed? | resource=Problem resource
- definitionUnmatched | reason=Specialization | pattern=Describes why the detected issue occurred in coded or textual form or Indicates another resource whose existence justifies this detected issue. | resource=Indicates the resource representing the current activity or proposed activity that is potentially problematic.
- commentsUnmatched | reason=Specialization | pattern=Textual reasons can be captured using reasonCode.text. | resource=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.
- Event.note → DetectedIssue.detail
- missingTypes | reason=Specialization | pattern=Annotation
- extraTypes | reason=Specialization
- shortUnmatched | reason=Specialization | pattern=Comments made about the event | resource=Description and context
- definitionUnmatched | reason=Specialization | pattern=Comments made about the detected issue by the performer, subject or other participants. | resource=A textual explanation of the detected issue.
Unmapped Elements
- Event.partOf — Unnecessary
- Event.reported — Unnecessary
- Event.relevantHistory — Unnecessary
- Event.location — Unnecessary
- Event.statusReason — Unnecessary
- Event.performer.function — Unnecessary
- Event.recorded — Unnecessary
- Event.product — Unnecessary
- Event.performer — Unnecessary
- Event.basedOn — Unknown
- Event.researchStudy — Unnecessary
detectedissue-fivews-mapping-exceptions.xml
Unmapped Elements
- FiveWs.recorded — Unnecessary
- FiveWs.actor — Unnecessary
- FiveWs.cause — Unnecessary
- FiveWs.version — Unnecessary
- FiveWs.witness — Unnecessary
- FiveWs.where — Unnecessary
- FiveWs.init — Unnecessary
- FiveWs.source — Unnecessary
- FiveWs.who — Unnecessary
- FiveWs.planned — Unnecessary