Skip to content

DetectedIssue Profile

Canonical../StructureDefinition/nexus-emr-core-detectedissue
Statusdraft (experimental) · 1.26.0
BaseDetectedIssue (constraint)
SourceFSH · JSON

Nexus EMR profile for DetectedIssue -- drug-drug and drug-allergy interaction findings raised during prescribing, and the prescriber's recorded override of them. First pass: models the override audit trail; the severity mapping is not yet settled.

Overview

Overview

The Nexus EMR Core DetectedIssue profile is the prescribing-safety layer: drug-drug and drug-allergy interaction findings raised during prescribing, together with the prescriber's recorded decision about them. An overridden finding is written back in the same transaction bundle as the MedicationRequest it gates, so the prescription and the recorded reason for accepting its risk commit together or not at all.

The profile is #draft and experimental = true. It is a first pass: a skeleton plus the constraints that are load-bearing for the override audit trail. It is now reachable by a SMART on FHIR app for read, search, create and update: the profile declares smart-exposed -- this guide's positive flag for app reachability -- and the server capability statement lists it. Deletion is not granted, and that is the point: the override rationale on a screening issue is a medico-legal record, so it is superseded rather than removed.

THE effective date is identifiedDateTime, falling back to identifiedPeriod.start. It is not the date of the medication concerned: an issue raised today about a long-standing prescription dates to today, which is what puts it in front of the clinician at the moment it is raised. patient (0..1, NexusEmrCorePatient) is left optional because a screening result computed before any patient context -- a bare drug-pair lookup -- legitimately has none; anything persisted against a chart should carry it. implicated (0..*) names the resources whose combination raised the finding: two or more MedicationRequests for a drug-drug interaction, or a MedicationRequest plus an AllergyIntolerance for drug-allergy. Per the Nexus EMR logical-reference model these may be identifier-only, so do not assume a resolvable literal reference.

Mitigation is the override axis. status is not

When a prescriber proceeds past a safety warning the rationale lands in mitigation (0..*), and the presence of a mitigation is what marks the issue as accepted:

  • status (1..1) does not change. The screening layer writes final for a result it stands behind; an overridden issue stays final and gains a mitigation. It does not become cancelled.
  • A reader that filters on status to decide what is still live will therefore display overridden interactions as active warnings. Filter on the presence of mitigation instead.

mitigation.action is 1..1 and carries the override rationale in .text. A warning-severity invariant (detectedissue-mitigation-has-rationale) recommends rationale text or a coding on every mitigation; it is a warning rather than an error because system-generated mitigations legitimately have neither. mitigation.author (0..1, NexusEmrCorePractitioner or NexusEmrCorePractitionerRole) should be populated -- an override with no attributable author is a weak record even when the rationale is present. mitigation.date is 0..1.

code is written text-only, and positional access will break

code is 0..1 and is currently written text-only by the screening layer. Text-only is fully conformant for a CodeableConcept, so:

  • Readers MUST NOT index positionally into code.coding. code.coding[0] is absent on the instances produced today, and once codings do appear nothing guarantees the first is the interaction-type concept rather than a source-system or vendor code.
  • Read code.text for display and treat any coding as additive rather than as the primary value.
  • The same applies to mitigation.action, also text-only today: handle a CodeableConcept with no coding.

Coding code against detectedissue-category is expected follow-up and is not settled. Write consumers so that the arrival of codings is additive.

severity is not a contract yet

severity is 0..1 and inherits R4's required binding to detectedissue-severity (high | moderate | low). The screening engine has its own severity scale and the mapping onto that binding has not been agreed. Do not treat the values currently emitted as stable, and do not gate clinical display solely on severity; the finding text and the implicated resources are the durable signal.

Also unresolved: whether findings are retained after the prescription that triggered them is abandoned. Until that is decided, the absence of a DetectedIssue is not evidence that no issue was raised.