Imaging Diagnostic Report
0.0.1-current - ci-build
Imaging Diagnostic Report
0.0.1-current - ci-build
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 https://github.com/IHE/RAD.IDR/ and changes regularly. See the Directory of published versions
The Imaging Diagnostic Report Profile describes a machine-readable format for reports on diagnostic procedures of common radiology specialties using common modalities. It defines a FHIR-based encoding of the report, specifically addressing standard imaging report sections, including order, history, procedure/technique, comparison, findings/observations, impression/conclusion, recommendations, and signatures.
Specific attention is given to the impression and recommendation content as being of primary interest to the main consumers of diagnostic reports. Machine-readable coding of this content facilitates machine support such as placing orders for recommended followups or clinical decision support driven by report impression content.
TODO Add Out of Scope text here
TODO Tweak img src references and scaling as needed TODO Find “See” and “Section” and add links
This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at https://profiles.ihe.net/GeneralIntro/.
Figure 56.1-1 shows the actors directly involved in the IDR Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a required grouping are shown in conjoined boxes (see Section 1:56.3).
Table 56.1-1 lists the transactions for each actor directly involved in the IMR Profile. To claim compliance with this profile, an actor SHALL support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).
Table 56.1-1: IDR Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
| Report Creator | Store Imaging Diagnostic Report [RAD-Y1] | Initiator | R | RAD TF-2: 4.Y1 |
| Report Repository | Store Imaging Diagnostic Report [RAD-Y1] | Responder | R | RAD TF-2: 4.Y1 |
| Query Imaging Diagnostic Report [RAD-Y2] | Responder | R | RAD TF-2: 4.Y2 | |
| Retrieve Imaging Diagnostic Report [RAD-Y3] | Responder | R | RAD TF-2: 4.Y3 | |
| Report Reader | Query Imaging Diagnostic Report [RAD-Y2] | Initiator | R | RAD TF-2: 4.Y2 |
| Retrieve Imaging Diagnostic Report [RAD-Y3] | Initiator | R | RAD TF-2: 4.Y3 | |
| Report Consumer | Query Imaging Diagnostic Report [RAD-Y2] | Initiator | R | RAD TF-2: 4.Y2 |
| Retrieve Imaging Diagnostic Report [RAD-Y3] | Initiator | R | RAD TF-2: 4.Y3 |
Most requirements are documented in RAD TF-2: Transactions. This section documents any additional requirements on profile’s actors.
A Report Creator coordinates the composition of the content of an imaging diagnostic report.
A Report Creator encodes diagnostic reports using FHIR DiagnosticReport resources. Systems that might implement this actor include traditional reporting products. It is also conceivable that a broker product might be able to take reports in some other format and compose an equivalent report encoded according to this profile.
Each resulting DiagnosticReport resource also includes at least one rendered report in HTML format in the same DiagnosticReport resource, either as base64 encoded binary, or by reference using a URL.
A Report Repository stores reports received from Report Creators and makes the reports available for other consumers through query/retrieve.
A Report Repository may modify how referenced resources are made available for subsequent access by systems that retrieve the report. This may be done to improve accessibility to consumer systems outside the local network, or may be done to improve efficiency of retrieval. For example, a Report Repository may adjust an internal URL to an externally accessible URL, or it may retrieve the rendered report referenced by a URL and embed it directly, base64 encoded, in the DiagnosticReport resource in a query response.
A Report Reader accesses reports from the Report Repository for presentation to a user.
Report Readers shall be able to present the XHTML content of DiagnosticReport.text. Report Readers shall be able to present PDFs referenced in DiagnosticReport.presentedForm, if any are present. Report Readers may choose to render coded content from the report, or present additional pre-rendered versions contained or referenced in the .presentedForm, or some combination of that.
Systems that might implement this actor include EMRs, enterprise viewers, and patient portals. A reporting workstation might also implement this actor to access and present prior reports, in whole or in part, to the imaging clinician.
A Report Consumer accesses reports from the Report Repository for processing. The capabilities to process those reports is not otherwise constrained here. Systems that might implement this actor include clinical decision support (CDS) systems, workflow automation tools, and clinical registries. A reporting workstation might also implement this actor to access and incorporate content from prior reports into the current report.
Options that may be selected for each actor in this profile, if any, are listed in the Table 56.2-1. Dependencies between options, when applicable, are specified in notes.
Table 56.2-1: Imaging Diagnostic Report – Actors and Options
| Actor | Option Name | Reference |
|---|---|---|
| Report Creator | No options defined | -- |
| Report Repository | No options defined | -- |
| Report Reader | No options defined | -- |
| Report Consumer | No options defined | -- |
An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2).
Section 56.5 describes some optional groupings that may be of interest for security considerations and Section 56.6 describes some optional groupings in other related profiles.
Table 56.3-1: Imaging Diagnostic Report – Required Actor Groupings
| IDR Actor | Actor(s) to be grouped with | Reference | Content Bindings Reference |
|---|---|---|---|
| Report Creator | ITI CT / Time Client | ITI TF-1: 7.1 | -- |
| Report Repository | None | -- | -- |
| Report Reader | None | -- | -- |
| Report Consumer | None | -- | -- |
This section presents concepts and considerations that may be helpful to better understand, implement, and deploy this profile. This material is informative; there are no conformance requirements in this section.
For brevity, this section will sometimes refer to imaging diagnostic reports simply as “reports”.
The proposed FHIR DiagnosticReport format would take its place among a number of existing report formats in use, to varying degrees, in existing hospital systems. This profile does not mandate specific transcoding capabilities, but since that will likely be part of successful product implementations, some guidance is provided here.
HL7 V2 ORU messages containing formatted or unformatted text are, as of the early 2020’s, still a very common format for distributing reports. The primary advantage of this approach is its compatibility with the large install base of V2 systems, in particular when including the report in HL7 V2-driven electronic medical record systems. While the inclusion of OBX segments in the ORU message can provide some coded information, this is still poorly adopted and not well standardized. As a result, the machine-readability is quite low and the underlying mechanisms are not well suited to significant improvement of that.
Transcoding between ORU messages and DiagnosticReport will likely make use of the DiagnosticReport.text, and potentially DiagnosticReport.presentedForm.
PDF renderings of full reports are also popular due to being able to capture and reproduce well-formatted human-readable presentations of the content. However, PDF documents lack machine-readable coding of the content which undercuts the ability to support functions like clinical decision support, workflow automation, and clinical databases.
Transcoding PDF renderings can make direct use of the ability to include PDF documents in the DiagnosticReport.presentedForm. Report Creators that provide PDFs in created DiagnosticReports will facilitate consumption by simpler downstream systems.
DICOM Structured Report (SR) introduced mechanisms for fully coded clinical information contained in persistent documents with robust management. In practice this encoding has been predominantly used for objects created within the imaging department to capture measurements (echocardiography, fetal ultrasound, CT/MR oncology, etc.), radiation dose (x-ray RDSR, radiopharmaceutical RRDSR), contrast administration, computer-aided detection and diagnosis (CAD) results (mammography, chest radiography, etc.), and general procedure logs. While the SR format was also designed to support coded diagnostic reports, lack of format support where the reports are viewed, outside the imaging department, was an obstacle. When HL7 CDA was subsequently introduced, DICOM prepared a mapping and guidance for the use of CDA-based imaging diagnostic reports (See DICOM PS3.20).
Transcoding SR components, such as individual measurements and observations, addressed in part by activities in the joint DICOM WG-20/HL7 II Working Group. That work is directly relevant to coding SR components into the Findings section of a FHIR report. (See WG20 IG). Some of that guidance is relevant here, but it should be noted that this IDR Profile is scoped to first address the distribution and basic clinical consumption of imaging diagnostic reports and is thus focused most strongly on the Conclusions and Recommendations sections. Important subsequent IHE work will address the report creation process and more advanced consumption, which will delve deeper into the encoding of the Findings section, integration of AI inputs, research, incorporation of prior findings, etc., and make more use of the WG20 work.
HL7 Clinical Document Architecture (CDA) defines XML encodings for persistent clinical documents that can contain coded and uncoded content. CDA defines three levels of semantic interoperability (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC130066/):
Level 1 – xml-wrapped text
Level 2 – xml-wrapped text with section headers
Level 3 – xml-wrapped text with section headers and structured and coded data
where “Level 3” data constructs (called “entries”) enable individual structured and coded results.
When adopted, CDA usage is often closely associated with the IHE XD* family of profiles, however cross-enterprise sharing of machine-readable data is still limited.
Transcoding CDA diagnostic reports will benefit from much of the information in DICOM PS3.20 as described above.
Since CDA and FHIR are both HL7 defined encodings, several pieces of work within FHIR provide guidance on transcoding between CDA and FHIR resources in general:
The IHE Results Distribution (RD) Profile also provides relevant guidance on best practices when using ORU, PDF, SR and CDA for distributing imaging diagnostic report content.
HL7 FHIR DiagnosticReport Resources have the potential to permit sophisticated levels of machine-readable data while also providing human-friendly presentations of the report, all within a FHIR-based HIT environment. Those are some of the key motivations for this profile. Details on encoding imaging diagnostic reports based on the FHIR DiagnosticReport resource are provided in RAD TF-3:6.7 Imaging Diagnostic Report Content.
The imaging diagnostic report is a part of the patient’s medical record and is the definitive documentation of the results of an imaging examination or procedure. It includes the observations, measurements, and findings from the imaging examination. Importantly, it is also expected to include a summarization, interpretation (sometimes in the form of a differential diagnosis with probabilities), and management recommendations that draw from the patient’s full clinical history.
The report will have several types of readers. The referring physician will consider the differential diagnosis available in the report in the context of other information such as symptoms, physical examination, and past medical history to refine the likelihood of a certain disease and to guide next steps in management. He may use qualitative and quantitative data within the report to assess disease progression and treatment response. He may also review management recommendations within the report to guide further diagnostics, treatment, or referral to other providers. The report will also be read as a “prior” for comparison by radiologists who are reviewing the patient’s follow-up exams to focus attention on areas of concern and to further refine diagnosis and management recommendations. Finally, the report is often read by the patient and caregivers, often in conjunction with the referring physician, but also frequently on their own, to educate and support informed consent for next steps in management.
Machine-based consumers of reports will often be interested in specific individual data elements, such as a recommendation, a primary conclusion, or an actionable incidental finding (See subcases in Section 56.4.2.4 Use Case #4: Report Processing). Such qualitative and quantitative data may be used for a variety of purposes, including clinical decision support tools and trend analysis. Human readers of reports may be interested in the report as a whole, or may also focus on specific elements (See Section 56.4.2.3 Report Presentation). Presentation features involving hyperlinked report elements are addressed in the IHE Interactive Multimedia Report (IMR) Profile.
An important feature of imaging diagnostic reports is the organization of the content into sections intended to more efficiently and effectively communicate the information. The semantics of the sections are important. The same observation has different implications when present in the order, in the patient history, in the family history, or in the findings section of the report. “Flatlisting” into an undifferentiated collection of items can make the information more difficult to work with.
The content and ordering of the sections reflect organization of the content, not the dictation process. Some imaging clinicians may dictate content in different orders, or replace dictation of some content with the use of tools to populate parts of the report.
The American College of Radiology provides specific guidance in the ACR Practice Parameter for Communication of Diagnostic Imaging Findings on recommended report sections and content. While the titles may vary and the section groupings may differ slightly from practice to practice and from country to country, the approach of medical imaging clinicians to organizing report content is broadly consistent.
Note 1: Words are bolded to call attention to key details.
Note 2: Report sections and format are not formally standardized at some sites.
Note 3: When there is no content for a section in a given report, the section is sometimes omitted.
Patient information such as name, age, gender, birthdate, and medical record number is typically provided first.
The Patient and Order information are often presented at the top of the report in a pre-defined “header” section with formatted fields for a number of the key details. Typically, this information is populated automatically, not dictated by the imaging clinician.
Order information such as the accession#, the identity of the referring physician or organization, the indication for examination, and, ideally, additional patient context and specific clinical questions provided by the referring physician. Clinical questions are sometimes of the form “Follow-up X”, where X is an existing known finding (perhaps from a previous exam), or “Rule out X”, where X is a condition for which imaging input is requested on whether or not it is present. Indications are also, hopefully, provided to provide important clinical context to the imaging clinician, and to support assessment of the appropriateness of the order and/or billing. If indications are not present, they are sometimes sought out by imaging staff.
Note: “Rule out X”, while somewhat helpful for the imaging clinician, can be problematic for billing since the symptoms that suggest the possible presence of the condition and establish the medical necessity of the imaging exam are implied, but not captured. Site practices increasingly deprecate such wording.
History: This section includes patient history and other prior clinical details deemed relevant to the imaging study by the imaging clinician. Some information may be provided by the referring physician in the order, and more is extracted from the medical record by imaging staff, automated tools, or by the radiologist themselves. This information provides background for the imaging clinician, context for the contents of the report, and is sometimes relevant to billing and clinical guidelines. Potential sources include impressions or summaries of the clinical notes from the encounter where the imaging order was placed.
Procedure and Materials: This section contains information such as the procedure type, the anatomy imaged, the date and time of the imaging examination, and the facility that performed it.
Also called Imaging technique, this section may describe the parameters that were used, details of any contrast media and/or radiopharmaceuticals administered, including concentration, volume, and route of administration, and any medications, and catheters or devices used.
The section can also describe preparation of the data produced by the procedure: Views, image sets, recons, reformats and post processing.
Radiation dose may also be described here; the text content and metrics may be constrained/formatted to meet local regulations.
The information in this section is typically more detailed than what is listed as the Order, and in fact may differ from the ordered exam based on the needs of the patient and the judgment of the imaging clinician.
Any deficiencies of the study may also be described here, such as whether the imaging was incomplete or if there were quality issues that prevented interpretation of some part of the study or otherwise compromise the sensitivity and specificity of the examination. In the event that a patient was unable to undergo imaging, for example due to claustrophobia or a seizure, a report might still be produced and this section would note that the exam was not performed and provide a reason.
While the actual instructions given to the patient are not typically listed in the report, some mention the fact that instructions were given, and perhaps that risks were discussed, and consent was obtained. Procedure notes from the technologist are typically captured elsewhere, but significant details such as adverse patient reactions, or things that may affect the quality of the study, may be included here.
Procedure details that may be required for billing are sometimes included here as well.
Comparison: This section is a list of other studies that were considered relevant by the imaging clinician. They are typically identified by type (modality, anatomy, exam type) and date. Findings from these studies and comparisons with the current study are typically woven into the next section (e.g. indicating no change, differentiating descriptions and/or measurements), although some of these studies may not be specifically mentioned in the findings. It is typically presumed that both the images and the report for each comparison study were available to the imaging clinician, however in some cases, such as for external priors, only the report or only the images were available, in which case that may be noted here.
Findings: This section provides a detailed description of the findings on the imaging examination. The findings should be described in a clear and concise manner, using standardized anatomic, pathologic, and radiologic terminology whenever possible.
When there are significant numbers of findings, the imaging clinician will typically organize them into groups, typically by anatomy. Reporting templates for particular procedure types (such as those at radreport.org) will also often organize the findings.
An important distinction between Findings and Impressions is that Findings capture what the imaging clinician saw in the image, while Impressions capture what they inferred/concluded. The findings might record a radiolucency, while the impression records a fracture. There are some cases where the two overlap, but generally imaging clinicians try to capture in the Findings what the significant image features are and strive in the Impressions to communicate to the referring physician what they think those represent in clinical terms.
Impression, sometimes also called Conclusion or Diagnosis, provides the radiologist’s overall interpretation of the findings, a specific diagnosis and/or differential diagnosis (when possible), responses to any clinical questions posed by the referring physician, and any recommendations for further management and/or confirmation, as appropriate.
Recommendations most often cover subsequent diagnostic imaging or other diagnostic procedures such as biopsies or lab tests. They may also include suggestions to correlate the imaging result with other clinical information to improve the confidence of the diagnosis, referrals to specialists, or less commonly, therapeutic procedures. The recommendations may cite specific guidelines applied, particularly when the referring physician might be less familiar with the current guidelines for certain findings than the imaging clinician. The imaging clinician may take into account the expertise of the referring physician when composing recommendations; for an unusual cancer, a family physician might find follow-up recommendations more helpful than an oncology specialist would.
Since referring physicians may specifically focus their attention on this section, the imaging clinician may choose particularly important details such as key findings or any adverse events, to re-iterate and summarize here.
The order of items in the impression is often significant, in that imaging clinicians frequently put the most critical, most actionable, most significant items first in the impression section to minimize the chance of them being overlooked. In the case of differential diagnosis, the multiple possible diagnoses are typically presented in order from the most likely to the least likely. Impression items may also be numbered to facilitate verbal referencing or linking to communications.
Some items in the impression may be clinically significant but were not associated with the indications or reason for exam; for example, a lung nodule deemed to be suspicious on a chest exam for trauma. These are often referred to as “incidental findings”.
Some items in the impression may be considered actionable, in that some follow-up action or communication is advisable. The recommendations may or may not include a specific corresponding follow-up action. A corresponding communication to relevant persons may or may not have taken place during the reporting process and be noted in the report.
Some items in the impression may be critical, in that they represent the potential for severe negative clinical impact to the patient if appropriate action is not taken promptly. The presence of such items almost always results in a communication with care staff and/or the patient.
There is strong interest in tooling to facilitate communicating critical results clearly and rapidly with the appropriate people, confirming that follow-up of actionable findings takes place, and making sure that incidental findings do not “fall through the cracks”.
Communications are records in the report about attempted and/or successful communications of some content of the report to the referring physician, the patient, or other appropriate person. These communications are initiated during the generation of the DiagnosticReport by members of the organization fulfilling that order. E.g. direct communication of time critical results by the radiologist to the referring physician.
Communication is not listed as a separate section in the ACR guidance, but codes for a communication section do exist. It is common practice to present communication records at the bottom of the report, just below the impressions, since they are often driven by specific items in the impression and occur at the end of the report creation process. Such communication records support medico-legal usage and the review and improvement of conformance to best practices for patient safety and quality of care.
The communication entry typically records the date, time, and method of communication, the person/organization contacted, and may summarize the content communicated.
Signature, makes clear the identity and credentials of the author of the report and records their approval of the semantic content of the report as written.
Addendum, contains report information recorded subsequent to the report being distributed as final. Addenda may contain corrections, such as typographical or transcription errors, new findings that have come to the attention of the imaging clinician, additional procedure details needed to support billing or QA, additional observations requested by the referring physician, or re-interpretation of findings in light of additional clinical context.
There may be multiple addenda to a given report. Addenda can be authored by clinicians other than the original author of the report.
An addendum may contain just the supplementary information. Some systems present the addendum in a corresponding text box next to the original report. Based on local policies and practices, the addendum may also contain a complete “replacement” report. In either case, the original final report is always retained for medicolegal purposes. It can also serve as an effective way to resolve references.
It is important for addenda to be distributed promptly to all systems that received the original final report.
Note that ACR implies that for a brief report, some sections might not be specifically called out.
In general, it is left to the Report Creator implementers to address issues like interleaving content that is automatically generated and content provided by clinician dictation or input, or avoiding duplication of the same content in different sections, or ensuring the full content of the report is approved by the imaging clinician.
The Royal College of Radiologists (RCR) also provides guidance on communication with the referrer in Standards for interpretation and reporting of imaging investigations.
The purpose of the report is to provide a timely answer to the clinical questions posed, together with a holistic assessment of all the images for relevant and/or unexpected findings. The written report should be clear, and written in a way appropriate to the referrer’s expected level of familiarity with the imaging abnormalities detected, the implications for the patient and the referrer’s access to requesting further investigations. The wording of the report is likely to differ when it is written to a general practitioner (GP) who may be unfamiliar with a relatively rare condition, compared with a specialist in that particular field.
The report should be actionable and should therefore convey a knowledgeable and reasoned assessment of the examination and its contribution to the overall management of the patient.
The Key Performance Indicators identified by the RCR are:
The report should answer the clinical question: target 100%.
When an abnormality is described a tentative or differential diagnosis should be provided: target 100%
Not all reports will have advice on the next step. However, where advice is given, the advice should be appropriate: target 100%.
While this profile does not mandate the use of particular codesets for many of the details that are coded, agreeing within the local site or organization on common codesets will be a key prerequisite of effective deployment of this profile. This is necessary to facilitate automated functions such as those described in Section 56.4.2.4.1. Further, since reports are typically circulated to other organizations, the use of codes from widely adopted standards will be particularly important to realize the full potential of coded reports. Many of the examples in this profile demonstrate the use of SNOMED codes (indicated by an SCT coding system value). SNOMED has agreements with DICOM and FHIR that identify a very large set of codes which can be used free of charge in DICOM and FHIR implementations anywhere in the world, independent of national licensing. This profile permits implementations to use alternate coding systems, for example if they need to use codes outside of the aforementioned sets in countries that do not have SNOMED licensing agreements.
LOINC has a significant collection of codes for measurements that could be of significant value in coding Findings. LOINC is also the source of the sections codes in RAD TF-3: 6.7.3.0.1, which were drawn from the two panels defined in (81220-6, LN, Diagnostic imaging report – recommended C-CDA R2.0 and R2.1 sections) and (87416-4, LN, Diagnostic imaging report - recommended DICOM PS3.20 sections).
This section briefly introduces FHIR resources relevant to imaging diagnostic reports, and outlines their intended purpose, usage, and main details. The maturity level is shown in (parentheses).
Guidance on using these for encoding reports is provided in RAD TF-3: 6.7 (Imaging Diagnostic Report Content)
Note: Some of the relationships between these Resources are described in the Diagnostic Medicine Module.
The Patient Resource (N) encodes demographics and administrative information about an individual or animal receiving care. The resource appears fully adequate for imaging purposes and no need for imaging-specific modifications has been identified.
The ServiceRequest Resource (4) encodes an order for, in our case, a diagnostic imaging procedure. Instances of this resource are used to represent the imaging request being fulfilled by this report, and any draft requests for subsequent services recommended by the reporting physician. More profiling may be necessary to fully satisfy the workflow and record-keeping requirements of imaging procedures, but that is out of scope for this profile.
The Encounter Resource (4) describes an interaction between a patient and healthcare provider(s). Encounters can reference each other in a hierarchical structure; for example, an encounter with the imaging department might be a child of an encounter representing a hospital admission. Modelling and profiling encounters to represent imaging scenarios such as interventional procedures, outpatient imaging, pre-imaging preparation such as radiopharmaceutical injection, multi-stage imaging, etc. is out of scope for this profile. Instances of this resource may be used to represent the encounter where the imaging was performed, and possibly the encounter where the imaging was ordered.
Note: Resources that represent the basic information about a patient and a clinical encounter can be found in the Administration Module.
The Procedure Resource (4) encodes an action that was performed on a patient, such as a diagnostic imaging procedure, in our case in response to a ServiceRequest. The imaging Procedure is performed in the context of an imaging Encounter. Like ServiceRequest, more profiling of this resource may be required to fully satisfy the workflow and record-keeping requirements of imaging procedures, but that is out of scope for this profile.
The ImagingStudy Resource (4) represents the content produced in a DICOM imaging study. This is the primary output of one or more diagnostic imaging Procedures, typically in response to an imaging ServiceRequest. Instances of this resource are used to represent the imaging study being reported on, comparison studies available to the reporting physician, and possibly other studies to which they referred.
The DiagnosticReport Resource (3) encodes findings and interpretation of diagnostic tests performed, in our case, on patients. The resource contains information about the test and the subject. It references a variety of other resources, including the Patient, ServiceRequest, Procedure, ImagingStudy, and Observations and Conditions identified in the imaging, or as part of the relevant patient history.
Note: FHIR notes that DiagnosticReport “is not intended to support cumulative result presentation (tabular presentation of past and present results in the resource).” This profile does not rule out the inclusion of prior results, such as measurements for oncology, cardiology, or obstetrics, which might usefully be presented in a table format; however, it is acknowledged that the “source of truth” of those prior measurements is the prior report, not the current one.
The DiagnosticReport resource has also been profiled by the IHE IMR Profile.
The ImagingSelection Resource (2) encodes a selection of a specific portion of an imaging study to permit linkage to Observation and other resources that describe such a specific subset. The selection starts at the level of specific DICOM SOP instances and/or frames within a single Study and Series. It may include additional specifics such as an image region, an Observation UID or a Segmentation Number. One of its intended applications is to support encoding the spatial details of findings and impressions in diagnostic imaging reports.
The Observation Resource (N) encodes individual observed details such as those that appear in the findings and impressions of imaging diagnostic reports. Observation supports nesting and other relationship mechanisms to capture groups of associated observations.
The Condition Resource (5) encodes a clinical condition, problem, or diagnosis. The verification status of the condition can include unconfirmed, provisional, differential, and confirmed. Instances of this resource are used to represent confirmed or possible conditions identified by the reporting physician, as well as conditions that are part of the study indications or relevant history of the patient or their family.
The Bundle Resource (N) is a container for a set of related resources. It can be used for a variety of purposes related to data organization, storage, and messaging. Instances of this resource are used to collect the set of resources that together comprise an imaging diagnostic report for transmission as a semantically complete report.
The Composition Resource (4) represents a document in the sense of a specific presentation of a specific collection of referenced resources. The composition does not affect the meaning of the referenced resources, but rather arranges them to optimize consumption by a particular type of consumer or use case. Different compositions may be created that reference the same resources for different consumers, e.g., to highlight clinical vs operational content. In some ways, compositions are analogous to DICOM Presentation States. Additional metadata captures the subject (patient), document type, author, title, creation date, status (prelim, final), and confidentiality. A composition can be signed/attested. Like instances, they are intended to be immutable once created. Changes require a new “version”. Instances of this resource may be referenced inside a DiagnosticReport to encode different presentations of the content (potentially as an alternative to providing different presentedForms).
Note 1: The FHIR Breast Radiology IG in R4 opted to use Composition instead of DiagnosticReport, reportedly in the belief that DiagnosticReport would be dropped. US Core opted to use DiagnosticReport instead of Composition. FHIR advises “If you have a highly structured report, then use DiagnosticReport – it has data and workflow support.”, which is the approach taken in this profile. See also RAD TF-4: 5.2.
Note 2: FHIR says “Composition may also be used to organize observations and diagnostic reports, but that is only for purpose of readability, not to record critical relationships for interpretations.”
The DocumentReference Resource (4) is basically a pointer to a document, such as a diagnostic report, serving as an index entry and possibly providing access path information. It replicates organizational metadata like the document type, format (Composition, PDF, CDA, SR), creation date, author, status, and signatures. The resource apparently may also include the document as inline base64 encoded data rather than providing a reference pointer (which raises a variety of implications).
Note 1: FHIR says “a DocumentReference typically reflects a non-FHIR object that is not a FHIR Document (e.g., an existing C-CDA document, a scan of a driver’s license, or narrative note).”
Note 2: FHIR also says “This resource is able to contain medical images in a DICOM format.” while also noting that ImagingStudy and WADO-RS are the preferred method for indexing and accessing images. It will be left to future profiling work to determine whether this use of DocumentReference is introducing potential interoperability issues with how images are managed, indexed, exchanged, and presented in different scenarios.
There are also some FHIR data types that are useful to highlight and differentiate.
CodeableConcept includes a coding element and a text element, both of which are optional. It is permitted to have just a code, or just a text string, or both. It is also permitted to have multiple (synonym) codes.
CodeableReference, in a similar fashion, includes a resource instance reference and a CodeableConcept, both of which are optional. When a CodeableReference element is constrained to a list of Resource types, that constrains what may be referenced in the .reference element, but the .concept element is not constrained.
This profile does not address the workflow involved in arriving at a final report (which can be quite complex and involve interactions between multiple clinicians and staff including attending, resident, and overreading physicians), but it does address the metadata inside a published report that identifies the “state” of the encoded content.
This profile describes the content and encoding of a report that has reached the point of being suitable for “publishing” for use in patient care. While the relevant resources may exist in a partially populated form during the preceding report composition process, that is not addressed here.
Publishable reports may be preliminary, meaning that they are accessible to clinicians who may need initial information urgently, but at least one review and approval remains before the report is considered final.
Publishable reports will typically become final, meaning that they have been approved and signed, and should be distributed according to local practices.
Once made final, any amendments to the report are handled as an addendum.
Once a final report is published, preliminary reports are typically sequestered or removed from the medical record. In the case of an addendum, however, the corresponding final report is always retained for medicolegal reasons.
Since multiple instances of a given report may exist over time reflecting the above states, systems that handle imaging reports should, thus, expect to encounter multiple “copies” of a report that differ, or to encounter a retrieved current report that has different content than when retrieved previously. The metadata described in RAD TF-3: 6.7.3 Imaging Diagnostic Report Encodings will help systems understand and deal with such situations.
Historically, reports have been entirely narrative with a small amount of coded metadata for management. For example, when communicated in an HL7 V2 ORU message, the narrative may be prefixed by just the encoded patient name, MRN, Accession #, and date/time of the exam.
Providing report details as coded content makes that information machine-readable which opens the door to automated and semi-automated functions in systems that receive and process the diagnostic reports. The focus then shifts to considering what automated functions are of interest, and what report details they need in coded form to be able to operate effectively. Given that coding the entire content of the diagnostic report will be an enormous piece of work, identifying the functions that would provide the most value and utility also helps prioritize which parts of the report we should consider coding first. For additional discussion, see Section 56.4.2.4.1 Report Processing Use Case.
The target of this profile is to capture today’s narrative text reports in a FHIR encoding that includes metadata for intelligent handling and starts coding key pieces of content, such as the impressions and recommendations, to facilitate automated workflows. This is intended to start the transition to FHIR-based reports. Subsequent profiles will tackle coding increasing amounts of the semantic content of the reports, especially findings, to support additional use cases. Some principles the committee has discussed include:
All elements present in the report in coded form are also visible in the rendered .text (and typically in .presentedForms, if present).
Some data generated for/during the reporting process goes into the study, not into the report. i.e., Report is not the transport for additional data that isn’t “in the report”
Some elements in the report are there to support billing and administrative processes, not clinical processes.
Someday, all (or at least more) semantics visible in the .text (one or more of the .presentedForm, if present) will be present in the report in coded form.
It will help, when adding more coding specs, to be use case driven
As documented in RAD TF-3: 6.7.3 Imaging Diagnostic Report Encodings, the referenced resources are the primary containers for the coded report information, the DiagnosticReport.text is the primary container for the report narrative and is readily rendered for human consumption and readily parsed for machine consumption. The DiagnosticReport.presentedForm may optionally provide additional renderings for various use cases, such as fixed PDF presentations of the content, or HTML presentations that leverage features not available in the .text XHTML. The DiagnosticReport.composition may also optionally provide additional arrangements of the content to suit particular use cases or user preferences.
Hybrid environments (mixing FHIR and HL7 V2 messaging) are inevitable. If FHIR is the primary stored representation of the report, it will inevitably need to be sent to a text/V2 based environment. This will be an important part of making deployment practical in existing hospitals.
HL7 is working on general guidance for conversion of content that is encoded in HL7 v2 Messages into roughly equivalent FHIR resources (https://build.fhir.org/ig/HL7/v2-to-fhir/)
Future revisions of this document might provide guidance specific to imaging diagnostic reports and related resources.
A Report Creator encodes the report content.
The focus here is on encoding the collection of information at the end of the interpretation process into a DiagnosticReport-based format.
Marshalling the constellation of input data and interacting with that data during the interpretation process and assembling the report content is briefly discussed and shown here for context, but is not addressed by this specification.
Note: Other profiles that touch on that area (See Section 56.6 Cross Profile Considerations) include:
- Integrated Reporting Applications (IRA)
- AI Results (AIR)
- Remote Radiology Reporting Workflow (RRR-WF)
- Management of Radiology Reporting Templates (MRRT)
The Report Creator receives report content from multiple sources. Traditionally, the bulk of the content comes directly from the interpreting clinician via a dictation system. Some content, such as procedure, technique, and dose information, may be automatically extracted from the study instances and/or HL7 order artifacts. Additional content may be generated by clinical software (conventional or AI-based) in the form of proposed measurements, segmentations, image features, and other data analysis. The methods used by the Report Creator to arrive at encoded content that is approved by the reporting clinician is not constrained by this profile. For example, the Report Creator might use a Large Language Model (LLM) to extract coded elements from the dictated narrative, or it might provide an interface for the clinician to quickly select coded elements. The Report Creator might have the referring clinician approve the entire report content at the end, or might get piecewise approval during composition.
A report may be circulated when it is created in a preliminary state and again later when it has been signed and updated to a final state, and potentially again if it is updated again with an addendum to the report. That status is captured in the encoding (TOLINK See RAD TF-3: 6.7.3.0) but managing that transition and handling of multiple versions of the report is left to subsequent reporting workflow profile work.
The created report is expected to include both narrative and coded content. See Section 56.4.1.6 for a discussion of the balance and overlap between the two.
A Report Creator provides encoded reports to a Repository (push), which then makes the reports (and the associated component resources) available for routing and/or retrieval (pull).
This diagram shows the Report Creator sending the report directly to the Report Repository that serves as the storage server for subsequent query and retrieve transactions. Alternatively, the Report Creator might send the report to a Report Manager which handles short term workflows and dataflows and later migrates the report to the Report Repository for archiving.
This diagram shows the Report Consumer querying the Report Repository to identify a report of interest. Alternatively, the Report Consumer might be Report Reader in an EMR terminal where the referring physician has found a reference to the report (perhaps in the patient’s folder or perhaps attached to recently placed orders) which allows a retrieval based on that reference, skipping the query.
It is also important to note that some Report Consumers may do resource-level queries on some of the components of the report, e.g., the Observations, Conditions, and Service Requests that make up the Findings, Impressions, and Recommendations. For more detail, see Section 56.4.2.4 Report Processing.
Not shown in the diagram, some sites may configure Report Creators and/or Report Repositories and/or a special report router to push copies of all/most reports to additional destinations, such as a regional health information exchange, or patient portal system. The use case where specific reports are routed to particular destinations based on certain conditions and particular metadata values is framed as a report processing use case and is discussed in Section 56.4.2.4.1.5 Smart Routing of Reports.
The EMR (Electronic Medical Record), in the role of either Report Reader or Report Repository, will likely index reports for browsing, in addition to using the query/retrieve model. The imaging study would appear as an entry in the medical record with an associated datetime, body part, and modality or exam type. The report may appear in a list of patient documents, also with an associated datetime, body part, and modality or exam type. The originating order will appear in the medical record, but references go from the DiagnosticReport and ImagingStudy resources to the ServiceRequest resource, not the other way around. So going from the ServiceRequest to the report involves a query for the matching Accession Number, or ServiceRequest reference, rather than navigating the reference from the ServiceRequest.
Query patterns will vary by practice and no specific query capabilities are required beyond that described in the Query Imaging Diagnostic Report [RAD-Y2] transaction . That said, the following are query scenarios and capabilities that would likely be useful to some sites.
The most common patterns (which cover primary clinical usage) include:
Patient-based – find reports for a certain Patient
For a given Patient, find reports that reference it as .subject
Query by surgery department for images and reports for patients scheduled for surgery to do pre-surgical planning by each surgeon
Query by admin staff for recent reports and images for a given patient to prepare for data export in support of a patient transfer or referral for care in a different institution.
Order-based – find reports created for a certain Order.
For a given ServiceRequest, find reports that reference it as .basedOn
For a given Accession #, find the corresponding ServiceRequest, then find report
For a given Practitioner, find ServiceRequests that reference them as .requester, then find reports for those ServiceRequests
Query by a referring for ordered report based on accession number, patient, study datetime, body part, and possibly modality or procedure
Query by referring staff for reports from all procedures ordered recently their referring name/ID/practice to prepare for daily review and preparation
Study-based – find reports on a certain Study
Query by a reading radiologist for priors based on patient, datetime range, body part/region, modality, procedure type, and possibly impressions or finding values. Might need free text matching in the report body using NLP (could be client-side or server-side)
Query by a tumor board for reports, key images, and cross-indexed lab and anatomical histopathology results, for the list of scheduled patients/cases
Less common patterns (which also cover administrative and research use cases) may include:
Author-based – find reports certain contributors contributed to (to see how many studies of a certain type, or go back and find a report from today to check on).
For a given Practitioner, find reports that reference it as .resultsInterpreter
For a given Device, find reports that reference it as ??? FHIRQ TODO
Query by reading radiologist for reports authored by them (or perhaps their attending for a resident) with a particular impression or finding to see “how did I describe that last time”.
Prior-based – find reports that cite a certain prior (perhaps there was a quality issue)
Cohort-based – find reports with certain clinical or demographic factors
For a given Condition, find reports that reference it as .impression
For a given demographic, find Patients that match, then find reports for those .subjects
For a given modality, find ImagingStudy with a matching .series.modality, then find reports for those
Query by researcher for studies with certain patient characteristics, indications, impression/conclusions to prepare research/paper
Observation-based – find observations that were created as findings, without necessarily considering the entire report.
Caveat: due to pre-post coordination variations, actually making Observation queries functional might be a challenge.
Caveat: some observations might not have been coded.
Caveat: if diagnoses are coded under .conclusionCodes rather than Condition resources under .impressions, they would not be available as separate Resources for query.
Query by CDS agent for specific observations and observation values that are the basis for clinical guidelines to be applied to the patient/case.
One could also imagine many of the above queries coming from another institution. Dealing with the associated code mapping, patient matching, access permissions and other privacy and security details are not addressed in this profile.
A Report Reader presents the content of the diagnostic report to users performing clinical tasks.
The most basic form of presentation will be the full display of the entire report, as provided in DiagnosticReport.text as XHTML. Additional presentations may be present in DiagnosticReport.presentedForm, which might be a PDF, HTML, or formatted text. Report Readers will rely heavily on the .text (and presentedForm, if present) until key parts of the semantic content of the report is in coded form.
Some Report Reader implementations may serve the needs of users with specific roles and goals by providing more advanced functions, such as highlighting key elements relevant to the users task/interest, re-ordering or collapsing and expanding sections based on user focus, or providing summarizations.
Some roles and goals to consider include:
Referring Clinician
Surgeon
Oncologist
Emergency Physician
Radiologist
Patient
Understanding the impressions, recommendations, and other report content, as part of providing informed consent for a subsequent treatment procedure (this might involve re-wording the impressions and other parts of the report to match the patient’s education level and preferred language)
It can be especially useful to engage patients in tracking incidental findings and long-term follow-up recommendations.
Registrar (of a registry; public health, cancer, etc.)
Report Readers will need to pay particular attention to addenda (if any) to the report, as these can contain information that is critical to patient care. In some systems, an addendum is presented together with the impression since the impression is the section that gets the most attention.
Support for hyperlinks in the report body to trigger presentation of associated images and measurements is addressed in the Interactive Multimedia Report (IMR) Profile.
A Report Consumer extracts and processes relevant details from the diagnostic report.
This Use Case focuses on the extraction and processing of information from the Imaging Report and the other Resources with which it is encoded. The query and retrieves that make up the transactional part of this use case are described in Section 56.4.2.2 Report Storage and Distribution.
It is worth highlighting that many of the potential Report Consumers may have very specific tasks to perform and correspondingly may be focused on certain details (e.g. the impressions and recommendations) rather than the report as a whole. Several examples are described here.
It is also important to note that some Report Consumers may do resource-level queries on some of the components of the report, e.g., the Conditions, Service Requests, and Observations that make up the Impressions, Recommendations, and Findings.
The following subsections describe some specific examples of report processing.
Upon receiving an imaging diagnostic report, the referring physician may often want to place an order for follow-up studies recommended by the imaging clinician in the report.
The software used by the referring physician could start by extracting the ServiceRequest resources referenced in the DiagnosticReport recommendations. These already contain details such as the type of imaging procedure and suggested time frame which could be presented to the referring physician to select those they want to order now. The software might fill in additional details based on its configuration and local information, and ask the referring for the remaining details, if any. The software might also be able to interact with payer pre-approval systems.
The software might also be able to facilitate recommendations for non-imaging services such as biopsies, additional lab tests, referrals to other providers, etc. Some of those services might be related to the imaging recommendations (e.g. check for renal function and thyroid function before contrast administration). See Section 4.2.4.1.3.
Clinical Decision Support (CDS) systems analyze information from the health record to improve the efficiency or accuracy of care provider activities, such as subsequent patient care steps. CDS functions may be based on qualitative and quantitative data like the impressions and findings in the diagnostic report potentially combined with guidelines and other details from the medical record.
CDS outputs may take the form of computerized alerts and reminders, integration with clinical guidelines, diagnostic support, and/or execution of condition-specific order sets in the electronic medical record. In particular, the ACR *-RADS categories frequently have specific follow-up actions associated with them.
The CDS software used by the referring physician may have access to prior reports or clinical information that was not available to the imaging clinician.
A specific goal of this profile is to allow imaging clinicians to tag impression items that constitute actionable findings and indicate the rough time horizon of urgency. (See the text on Condition.actionable in RAD TF-3: 6.7.3.7).
Failure to notice and/or effectively follow-up on actionable findings (particularly non-critical actionable findings which are important but allow for a longer time horizon) is a known problem. The IHE Results Distribution (RD) Profile specifically included HL7 v2 mechanisms to try and improve this.
The software used by the referring physician could trigger off the actionability flag on all impressions in the DiagnosticReport and highlight or otherwise ensure that the referring physician is made aware of them. The patient portal software could similarly provide notifications and reminders to the patient.
The ACR has reported that “Up to 10% of all radiology reports contain follow-up recommendations, and approximately half of the recommended follow-up exams are never performed. Lung nodules represent about half of all imaging follow-up recommendations, and noncompliance with radiology lung nodule follow-up places patients at risk for delayed diagnosis of lung cancer.”
Patient and referring physician software could review on all recommendation ServiceRequests and check the clinical records to see if an actual ServiceRequest manifested and was performed within the suggested time frame. Alternatively, this might be done as a two-step process. First an algorithm could extract and assess all recommendations in every report. Those determined to be significant (and/or likely to be overlooked) would be forwarded to an intelligent tracking and notification system.
Note: It is important to be careful of false positives to avoid alert fatigue. Recommendations might not have been performed because the condition was not met, or an alternative procedure was performed.
The imaging clinician may also benefit from software that tracks follow-up of actionable findings and recommendations. Based on personal choice, local practice guidelines, or regional regulations, the imaging clinician may wish to be notified or provided a dashboard when certain time thresholds have passed without follow-up, or they may wish to review the results when follow-ups take place.
Registries are systems that collect data from multiple practice settings to improve the understanding of clinical conditions, other systems, and processes. Examples include the ACR Lung Cancer Screening Registry or the Pediatric Echo Registry. Since many submission processes are manual, the scale of submissions is quite restricted.
Submission software could start by extracting details from the report such as coded indications of certain diagnoses, and related information from the EMR. The software could vet reports to see if they meet the registry criteria, extract necessary details for submission, and perform any required anonymizations.
Because such registries might have specific code set transcoding requirements and other constraints, it is likely this use case would involve making reports available to a submission software rather than, for example, the software used by the referring physicians doing it directly.
Other functions that could benefit from improved machine readability of imaging report impressions and recommendations are automated notification and routing algorithms.
First, speed of awareness and access can be improved when there are critical urgent results in the impressions, such as pulmonary emboli, intra-cranial hemorrhages, or unstable aneurysms. The imaging clinician will also be trying to communicate with the primary responsible physician directly, but there are often other members of the care team that would benefit from being informed, and sometimes electronic notifications and report routing can outpace telephone tag. Given the identity of the referring physician in the ServiceRequest, the routing system may have access to more up to date contact details than the imaging clinicians reporting workstation. Note also the special case where the patient has self-referred.
Second, particular things in the impressions and/or recommendations will be of interest to particular stakeholders such as the referring physician, ward nurse, emergency department, intensive care unit, surgeon, oncologist, other specialist, and the patient themselves.
Qualitative and quantitative data in the report could support a variety of QA processes at organizational and national levels.
To assess performance, findings present (or absent) in the report can be compared to data from other systems that are running in parallel within the facility, such as interpretive AI systems designed to detect specified patient conditions.
Observations in the report of poor image quality can be identified and trigger creation of quality logs (see IHE Reject Analysis and Monitoring Profile). Analysis of such data can determine if issues are occurring systematically, which can be an indicator of equipment malfunction or equipment operator neglect.
The software used by the referring physician could also facilitate interacting with other EMR structures such as the Problem List and Allergies (contrast) based on information provided in and extracted from the DiagnosticReport. This will likely involve some selection by the referring physician and some intelligence and sophistication from the software to judiciously suggest updates to the master lists. It is also important to consider removal of entries from those lists when appropriate to help combat “note bloat”.
Similarly, intelligent extraction of key details from the DiagnosticReport for inclusion in discharge notes, referral letters, and patient instructions could save time and energy.
Another useful workflow function that could be enabled is the often-discussed radiology-pathology correlation feedback. Many radiologists would appreciate a dashboard that collects certain impression entries, like nodules or masses that are suspicious for cancer, and tracks subsequent anatomical histopathology reports to extract information on which were malignant and which benign.
Imaging diagnostic reports contain personal health information (PHI) such as demographics, findings, and other clinical information. It is appropriate for products implementing the Imaging Diagnostic Report (IDR) Profile to include PHI security controls. Specifying such general mechanisms and features is outside the scope of this profile.
Similarly, products implementing the IDR Profile might implement general mechanisms and features for tamper-proofing, repudiation, and digital signatures, but specifying those is also outside the scope of this profile.
Attached files in the .presentedForm, such as PDF, can be susceptible to infection by viruses, and URLs included in the report and referenced resources can introduce security risks. While implementations should consider these, specifying those is outside the scope of this profile.
IMR – Interactive Multimedia Report
A Report Creator in IMR might be grouped with a Report Creator to incorporate multimedia hyperlinks in the created reports.
A Report Reader and/or a Rendered Report Reader in IMR might be grouped with a Report Reader to present, and allow the user to invoke, multimedia hyperlinks in the created reports.
IRA – Integrated Reporting Applications
A Report Creator in IRA might be grouped with a Report Creator to interact with other reporting applications during the interpretation and report composition process.
AIR – AI Results Profile
An Imaging Document Consumer in AIR might be grouped with a Report Creator to incorporate AI Result data in the interpretation and report composition process.
RRR-WF – Radiology Remote Reading Workflow
A Task Performer in RRR-WF might be grouped with a Report Creator to drive the reporting process from a reading worklist.
MRRT – Management of Radiology Reporting Templates
A Report Creator in MRRT might be grouped with a Report Creator to use report authoring templates to facilitate composition of findings and other report content by the imaging clinician.
AIW-I – AI Workflow for Imaging Profile
AIW-I manages AI processing. A reporting workflow manager might be directly involved in that workflow, but the Report Creator would not. It would interact with the resulting data objects in the imaging study.
RD – Results Distribution
A Report Creator in RD might be grouped with a Report Creator, Report Repository, or Report Consumer to initiate ORU-driven behaviors such as follow-up for critical findings.
SOLE – Standardized Operational Log of Events Profile
An Event Reporter in SOLE might be grouped with a Report Creator to log reporting events.
ATNA – Audit Trail and Node Authentication (with the Radiology Option)
A Secure Node in ATNA is recommended to be grouped with all IDR actors to secure the communication of, and record audit trails for, diagnostic reports.
WIA – Web-based Image Access
An Imaging Document Consumer in WIA might be grouped with a Report Reader to use DICOMweb to access and display images referenced in the ImagingStudy Resource which is referenced in DiagnosticReport.study.
XDS-I.b – Cross-Enterprise Document Sharing for Imaging
The XD* family of protocols facilitate sharing clinical documents in a variety of formats such as PDFs or CDA. This Profile (and other ITI Profiles) profile the use of FHIR as a format for encoding a variety of clinical documents. Describing how FHIR documents are exchanged in an XD* environment is a task for the IHE IT Infrastructure Domain and is outside the scope of this Profile.
That said, it is worth noting that for the purpose of accessing referenced images, the information in the ImagingStudy Resource (UIDs for Study, Series, and instances) closely mirrors the information contained in the Manifest described in XDS-I.b.
IG © 2024+ IHE Radiology Technical Committee. Package ihe.rad.idr#0.0.1-current based on FHIR 6.0.0-ballot3. Generated 2025-09-14
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change