Imaging Diagnostic Report
0.0.1-current - ci-build International flag

Imaging Diagnostic Report, published by IHE Radiology Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.0.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of and changes regularly. See the Directory of published versions

1:XX IDR Home

Official URL: Version: 0.0.1-current
Draft as of 2024-06-25 Computable Name: IHE_RAD_IDR

NOTE TO REVIEWERS: This Imaging Diagnostic Report (IDR) Implementation Guide is work-in-progress. The PDF published at IHE is the authoritative Public Comment draft. The reosurce profiles here for convenience only. There may be discrepancies between Section 6.Z in the PDF and this implementation guide.

The resource profiles defined in this implementation guide are light on description. Please refer to the PDF for detailed description, use context, constraints and additional implementation considerations.

There are no examples of a full DiagnosticReport using this profile yet.

This IDR Implementation Guide is intended to become complete and authoritative when IDR is published as Trial Implementation.

Significant Changes, Open and Closed Issues

Organization of This Guide

The top level resource is the Imaging Diagnostic Report. It references the following resource:

See also the Table of Contents and the index of Artifacts defined as part of this implementation guide.

Conformance Expectations

IHE uses the normative words: Shall, Should, and May according to standards conventions.

Must Support

The use of mustSupport in StructureDefinition profiles equivalent to the IHE use of R2 as defined in Appendix Z.

mustSupport of true - only has a meaning on items that are minimal cardinality of zero (0), and applies only to the source actor populating the data. The source actor shall populate the elements marked with MustSupport, if the concept is supported by the actor, a value exists, and security and consent rules permit. The consuming actors should handle these elements being populated or being absent/empty. Note that sometimes mustSupport will appear on elements with a minimal cardinality greater than zero (0), this is due to inheritance from a less constrained profile.