This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions Content Examples Detailed Descriptions Mappings Profiles 4.11 Resource Contraindication - Content This resource maintained by the Clinical Decision Support Work Group 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. 4.11.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 multiple actions/proposed actions or could be specific to a single action. It does not apply to administrative 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 is 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 AllergyIntolerance , and/or Alert 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. 4.11.2 Boundaries and Relationships This resources 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 Alert for other types of issues. This resource is limited to clinical issues associated with a proposed or ongoing action. It does not cover business/technical issues such as lack of permission, duplicate identifiers and other business rule violations. Business and technical issues are conveyed using the OperationOutcome resource. It is possible to have both OperationOutcome and Contraindication together , where the OperationOutcome might indicate that a requested action was rejected due to a clinical issue and the Contraindication provides the details of the issue. 4.11.3 Background and Context Contraindications 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 it 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 being managed (to avoid red flags being raised as part of downstream workflow). E.g. Noting that a duplicate therapy is actually intended. Decision-support generated contraindications 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 contraindications 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 OperationOutcome indicating that there was a warning or error associated with the request and a Contraindication providing the clinical details. (The OperationOutcome could point to the Contraindication via an extension.) In those circumstances where requested operations are rejected as a result of a contraindication, the workflow may support allowing the operation to be re-tried provided the identified contraindication is included as part of the submission (possibly also including a mitigation). In doing so, the sender acknowledges the contraindication and takes responsibility for it, thus allowing the requested operation to proceed. See Linking to Contraindications for guidance on how a Contraindication instance might be included as part of another operation. Systems that require such workflows should document expected behavior as part of their Conformance declarations. 4.11.4 Resource Content Structure UML XML JSON All Structure Name Flags Card. Type Description & Constraints Contraindication DomainResource Clinical issue with action patient Σ 0..1 Patient Associated patient category Σ 0..1 CodeableConcept E.g. Drug-drug, duplicate therapy, etc. ContraindicationCategory ( Required ) severity Σ 0..1 code high | medium | low ContraindicationSeverity ( Required ) implicated Σ 0..* Any Problem resource detail 0..1 string Description and context date Σ 0..1 dateTime When identified author Σ 0..1 Practitioner | Device Who found issue? identifier Σ 0..1 Identifier Unique id for the contraindication reference 0..1 uri Authority for issue mitigation 0..* Element Step taken to address action 1..1 CodeableConcept What mitigation? ContraindicationMitigationAction ( Required ) date 0..1 dateTime Date committed author 0..1 Practitioner Who is committing? UML Diagram Contraindication ( DomainResource ) Indicates the patient whose record the contraindication is associated with patient : Reference ( Patient ) 0..1 Identifies the general type of issue identified category : CodeableConcept 0..1 « Codes identifying the general type of contraindication. E.g. Drug-drug interaction, Timing issue, Duplicate therapy, etc. ContraindicationCategory » Indicates the degree of importance associated with the identified issue based on the potential impact on the patient severity : code 0..1 « Indicates the potential degree of impact of the identified issue on the patient ContraindicationSeverity » Indicates the resource representing the current activity or proposed activity that implicated : Reference ( Any ) 0..* A textual explanation of the contraindication detail : string 0..1 The date or date-time when the contraindication was initially identified date : dateTime 0..1 Identifies the provider or software that identified the author : Reference ( Practitioner | Device ) 0..1 Business identifier associated with the contraindication record identifier : Identifier 0..1 The literature, knowledge-base or similar reference that describes the propensity for the contraindication identified reference : uri 0..1 Mitigation Describes the action that was taken or the observation that was made that reduces/eliminates the risk associated with the identified contraindication action : CodeableConcept 1..1 « Codes describing steps taken to resolve the contraindication or other circumstances that mitigate the risk associated with the contraindication. E.g. 'added concurrent therapy', 'prior therapy documented', etc. ContraindicationMitigationAction » Indicates when the mitigating action was documented date : dateTime 0..1 Identifies the practitioner who determined the mitigation and takes responsibility for the mitigation step occurring author : Reference ( Practitioner ) 0..1 Indicates an action that has been taken or is committed to to reduce or eliminate the likelihood of the risk identified by the contraindicaiton from manifesting. Can also reflect an observation of known mitigating factors that may reduce/eliminate the need for any action mitigation 0..* XML Template < <!-- from --> <!-- from --> <</patient> <</category> < <</implicated> < < <</author> <</identifier> < < <</action> < <</author> </mitigation> </Contraindication> JSON Template { "resourceType" : "", // from // from " " " " " " " " " " " " " }] } Structure Name Flags Card. Type Description & Constraints Contraindication DomainResource Clinical issue with action patient Σ 0..1 Patient Associated patient category Σ 0..1 CodeableConcept E.g. Drug-drug, duplicate therapy, etc. ContraindicationCategory ( Required ) severity Σ 0..1 code high | medium | low ContraindicationSeverity ( Required ) implicated Σ 0..* Any Problem resource detail 0..1 string Description and context date Σ 0..1 dateTime When identified author Σ 0..1 Practitioner | Device Who found issue? identifier Σ 0..1 Identifier Unique id for the contraindication reference 0..1 uri Authority for issue mitigation 0..* Element Step taken to address action 1..1 CodeableConcept What mitigation? ContraindicationMitigationAction ( Required ) date 0..1 dateTime Date committed author 0..1 Practitioner Who is committing? UML Diagram Contraindication ( DomainResource ) Indicates the patient whose record the contraindication is associated with patient : Reference ( Patient ) 0..1 Identifies the general type of issue identified category : CodeableConcept 0..1 « Codes identifying the general type of contraindication. E.g. Drug-drug interaction, Timing issue, Duplicate therapy, etc. ContraindicationCategory » Indicates the degree of importance associated with the identified issue based on the potential impact on the patient severity : code 0..1 « Indicates the potential degree of impact of the identified issue on the patient ContraindicationSeverity » Indicates the resource representing the current activity or proposed activity that implicated : Reference ( Any ) 0..* A textual explanation of the contraindication detail : string 0..1 The date or date-time when the contraindication was initially identified date : dateTime 0..1 Identifies the provider or software that identified the author : Reference ( Practitioner | Device ) 0..1 Business identifier associated with the contraindication record identifier : Identifier 0..1 The literature, knowledge-base or similar reference that describes the propensity for the contraindication identified reference : uri 0..1 Mitigation Describes the action that was taken or the observation that was made that reduces/eliminates the risk associated with the identified contraindication action : CodeableConcept 1..1 « Codes describing steps taken to resolve the contraindication or other circumstances that mitigate the risk associated with the contraindication. E.g. 'added concurrent therapy', 'prior therapy documented', etc. ContraindicationMitigationAction » Indicates when the mitigating action was documented date : dateTime 0..1 Identifies the practitioner who determined the mitigation and takes responsibility for the mitigation step occurring author : Reference ( Practitioner ) 0..1 Indicates an action that has been taken or is committed to to reduce or eliminate the likelihood of the risk identified by the contraindicaiton from manifesting. Can also reflect an observation of known mitigating factors that may reduce/eliminate the need for any action mitigation 0..* XML Template < <!-- from --> <!-- from --> <</patient> <</category> < <</implicated> < < <</author> <</identifier> < < <</action> < <</author> </mitigation> </Contraindication> JSON Template { "resourceType" : "", // from // from " " " " " " " " " " " " " }] }   Alternate definitions: Schema / Schematron , Resource Profile ( XML , JSON ), Questionnaire 4.11.4.1 Terminology Bindings Path Definition Type Reference Contraindication.category Codes identifying the general type of contraindication. E.g. Drug-drug interaction, Timing issue, Duplicate therapy, etc. Required http://hl7.org/fhir/vs/contraindication-category Contraindication.severity Indicates the potential degree of impact of the identified issue on the patient Required http://hl7.org/fhir/v3/vs/SeverityObservation Contraindication.mitigation.action Codes describing steps taken to resolve the contraindication or other circumstances that mitigate the risk associated with the contraindication. E.g. 'added concurrent therapy', 'prior therapy documented', etc. Required http://hl7.org/fhir/vs/contraindication-mitigation-action 4.11.5 Linking to Contraindications Contraindication follows the pattern of linking from the resource created "second". As Contraindication 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 contraindication 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 contraindication directly. However, with contraindications that implicate multiple records, containment is more problematic. In some workflows, a contraindication might be deemed to be "owned" by the record whose creation triggers the contrindication 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 Contraindication and containment is not appropriate, an extension can be used. 4.11.6 Open Issues Would this be better named something like Issue or ClinicalIssue or Precaution or something like that? Are author, reference and/or mitigation (and its various parts) all part of the 80%? 4.11.7 Search Parameters Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services. Name Type Description Paths author reference Who found issue? Contraindication.author ( Device , Practitioner ) category token E.g. Drug-drug, duplicate therapy, etc. Contraindication.category date date When identified Contraindication.date identifier token Unique id for the contraindication Contraindication.identifier implicated reference Problem resource Contraindication.implicated (Any) patient reference Associated patient Contraindication.patient ( Patient ) © HL7.org 2011+. FHIR DSTU (v0.4.0-4902) generated on Fri, Mar 27, 2015 00:19+1100. Links: What's a DSTU? | Version History | Specification Map | Compare to DSTU1 | | Propose a change try { var currentTabIndex = sessionStorage.getItem('fhir-resource-tab-index'); } catch(exception){ if (navigator.userAgent.toLowerCase().indexof('msie') == -1) alert(exception); } if (!currentTabIndex) currentTabIndex = '0'; $( '#tabs' ).tabs({ active: currentTabIndex, activate: function( event, ui ) { var active = $('.selector').tabs('option', 'active'); currentTabIndex = ui.newTab.index(); try { sessionStorage.setItem('fhir-resource-tab-index', currentTabIndex); } catch(exception){ if (navigator.userAgent.toLowerCase().indexof('msie') == -1) alert(exception); } } });