4.10 4.14 Resource DetectedIssue - Content Resource DetectedIssue - Content

4.10.1 Scope and Usage 4.14.1 Scope and Usage 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

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 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 - metalic tatoos". These guidelines can be captured using the intended to be used in defining general prohibitions on actions such as "No NSAIDs", "No solid oral dose forms" or "No MRIs - metalic tatoos". These guidelines can be captured using the AllergyIntolerance , and/or , 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 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. or other resources.

4.10.2 Boundaries and Relationships 4.14.2 Boundaries and Relationships This resource only applies to documenting a risk associated with a specific planned or ongoing action, not a general propensity to risk. The latter would be handled using

This resource only applies to documenting a risk associated with a specific planned or ongoing action, not a general propensity to risk. The latter would be handled using AllergyIntolerance for substance-specific issues or for substance-specific issues or Flag for other types of issues. 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 and other business rule violations. Technical issues are conveyed using the OperationOutcome resource. It is possible to have both for other types of issues.

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 and other business rule violations. Technical issues are conveyed using the OperationOutcome and DetectedIssue together, where the resource. It is possible to have both OperationOutcome might indicate that a requested action was rejected due to a clinical issue and the and DetectedIssue provides the details of the issue. 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.

4.10.3 Background and Context 4.14.3 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

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 byproduct of performing some other sort of action, they may be included in the "response" to the requested action in the same manner as an ) 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 byproduct 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 . In fact, both may be present - the OperationOutcome indicating that there was a warning or error associated with the request and a indicating that there was a warning or error associated with the request and a DetectedIssue providing the clinical details. (The providing the clinical details. (The OperationOutcome could point to the 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 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 instance might be included as part of another operation.

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

• Structure
• UML
• XML
• JSON
• All

Structure

Name	Flags	Card.	Type	Description & Constraints Description & Constraints
DetectedIssue			DomainResource	Clinical issue with action Clinical issue with action
patient	Σ	0..1	Reference ( Patient )	Associated patient Associated patient
category	Σ	0..1	CodeableConcept	Issue Category, e.g. drug-drug, duplicate therapy, etc. Issue Category, e.g. drug-drug, duplicate therapy, etc. Detected Issue Category ( Detected Issue Category ( Preferred )
severity	Σ	0..1	code	high | moderate | low high | moderate | low DetectedIssueSeverity ( ( Required )
implicated	Σ	0..*	Reference ( Any )	Problem resource Problem resource
detail		0..1	string	Description and context Description and context
date	Σ	0..1	dateTime	When identified When identified
author	Σ	0..1	Reference ( Practitioner | | Device )	The provider or device that identified the issue The provider or device that identified the issue
identifier	Σ	0..1	Identifier	Unique id for the detected issue Unique id for the detected issue
reference		0..1	uri	Authority for issue Authority for issue
mitigation		0..*	BackboneElement	Step taken to address Step taken to address
action		1..1	CodeableConcept	What mitigation? What mitigation? Detected Issue Mitigation Action ( Detected Issue Mitigation Action ( Preferred )
date		0..1	dateTime	Date committed Date committed
author		0..1	Reference ( Practitioner )	Who is committing? Who is committing?
Documentation for this format Documentation for this format

<DetectedIssue xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <patient><!-- 0..1 Reference(Patient) Associated patient --></patient>
 <category><!-- 0..1 CodeableConcept Issue Category, e.g. drug-drug, duplicate therapy, etc. --></category>
 <severity value="[code]"/><!-- 0..1 high | moderate | low -->
 <implicated><!-- 0..* Reference(Any) Problem resource --></implicated>
 <detail value="[string]"/><!-- 0..1 Description and context -->
 <date value="[dateTime]"/><!-- 0..1 When identified -->
 <author><!-- 0..1 Reference(Practitioner|Device) The provider or device that identified the issue --></author>
 <identifier><!-- 0..1 Identifier Unique id for the detected issue --></identifier>
 <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) Who is committing? --></author>
 </mitigation>
</DetectedIssue>

{
  "resourceType" : "DetectedIssue",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "patient" : { Reference(Patient) }, // Associated patient
  "category" : { CodeableConcept }, // Issue Category, e.g. drug-drug, duplicate therapy, etc.
  "severity" : "<code>", // high | moderate | low
  "implicated" : [{ Reference(Any) }], // Problem resource
  "detail" : "<string>", // Description and context
  "date" : "<dateTime>", // When identified
  "author" : { Reference(Practitioner|Device) }, // The provider or device that identified the issue
  "identifier" : { Identifier }, // Unique id for the detected issue
  "reference" : "<uri>", // Authority for issue
  "mitigation" : [{ // Step taken to address
    "action" : { CodeableConcept }, // R!  What mitigation?
    "date" : "<dateTime>", // Date committed
    "author" : { Reference(Practitioner) } // Who is committing?
  }]
}

Structure

Name	Flags	Card.	Type	Description & Constraints Description & Constraints
DetectedIssue			DomainResource	Clinical issue with action Clinical issue with action
patient	Σ	0..1	Reference ( Patient )	Associated patient Associated patient
category	Σ	0..1	CodeableConcept	Issue Category, e.g. drug-drug, duplicate therapy, etc. Issue Category, e.g. drug-drug, duplicate therapy, etc. Detected Issue Category ( Detected Issue Category ( Preferred )
severity	Σ	0..1	code	high | moderate | low high | moderate | low DetectedIssueSeverity ( ( Required )
implicated	Σ	0..*	Reference ( Any )	Problem resource Problem resource
detail		0..1	string	Description and context Description and context
date	Σ	0..1	dateTime	When identified When identified
author	Σ	0..1	Reference ( Practitioner | | Device )	The provider or device that identified the issue The provider or device that identified the issue
identifier	Σ	0..1	Identifier	Unique id for the detected issue Unique id for the detected issue
reference		0..1	uri	Authority for issue Authority for issue
mitigation		0..*	BackboneElement	Step taken to address Step taken to address
action		1..1	CodeableConcept	What mitigation? What mitigation? Detected Issue Mitigation Action ( Detected Issue Mitigation Action ( Preferred )
date		0..1	dateTime	Date committed Date committed
author		0..1	Reference ( Practitioner )	Who is committing? Who is committing?
Documentation for this format Documentation for this format

UML Diagram UML Diagram

XML Template XML Template

<DetectedIssue xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <patient><!-- 0..1 Reference(Patient) Associated patient --></patient>
 <category><!-- 0..1 CodeableConcept Issue Category, e.g. drug-drug, duplicate therapy, etc. --></category>
 <severity value="[code]"/><!-- 0..1 high | moderate | low -->
 <implicated><!-- 0..* Reference(Any) Problem resource --></implicated>
 <detail value="[string]"/><!-- 0..1 Description and context -->
 <date value="[dateTime]"/><!-- 0..1 When identified -->
 <author><!-- 0..1 Reference(Practitioner|Device) The provider or device that identified the issue --></author>
 <identifier><!-- 0..1 Identifier Unique id for the detected issue --></identifier>
 <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) Who is committing? --></author>
 </mitigation>
</DetectedIssue>

JSON Template JSON Template

{
  "resourceType" : "DetectedIssue",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "patient" : { Reference(Patient) }, // Associated patient
  "category" : { CodeableConcept }, // Issue Category, e.g. drug-drug, duplicate therapy, etc.
  "severity" : "<code>", // high | moderate | low
  "implicated" : [{ Reference(Any) }], // Problem resource
  "detail" : "<string>", // Description and context
  "date" : "<dateTime>", // When identified
  "author" : { Reference(Practitioner|Device) }, // The provider or device that identified the issue
  "identifier" : { Identifier }, // Unique id for the detected issue
  "reference" : "<uri>", // Authority for issue
  "mitigation" : [{ // Step taken to address
    "action" : { CodeableConcept }, // R!  What mitigation?
    "date" : "<dateTime>", // Date committed
    "author" : { Reference(Practitioner) } // Who is committing?
  }]
}