diff --git a/.gitignore b/.gitignore index 8fa0eb5..1b7dbb6 100644 --- a/.gitignore +++ b/.gitignore @@ -9,4 +9,8 @@ /_gencontinuous.sh /_genonce.bat /_genonce.sh +/_updatePublisher.bat +/_updatePublisher.sh .DS_Store +/_build.bat +/_build.sh \ No newline at end of file diff --git a/README.md b/README.md index 0bdfcc2..fa46542 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,9 @@ # Status -This is the supplement template for IHE-Profiles using the IG publisher. repository is under-construction. Please try using it. If you have questions, contact John Moehrke. +This is the IHE Imaging Diagnostic Report (IDR) Profile in FHIR IG format. -Instructions [are found here](https://github.com/IHE/supplement-template/wiki/Getting-Started) +As of 2025 Feb, resolution of the 2024 Public Comments has been completed and the resulting Volume 1 content has been migrated into the TIDocMigration branch. +The intention is to complete migration including the FSH content in March. +For questions about the content, contact Kevin O'Donnell or Kinson Ho. + +This repository is based on the [FHIR IG template for IHE Profiles](https://github.com/IHE/supplement-template/wiki/Getting-Started) diff --git a/Requirements-fromNarrative.json b/Requirements-fromNarrative.json new file mode 100644 index 0000000..16e102c --- /dev/null +++ b/Requirements-fromNarrative.json @@ -0,0 +1,10 @@ +{ + "resourceType" : "Requirements", + "id" : "fromNarrative", + "url" : "https://profiles.ihe.net/RAD/IDR/Requirements/fromNarrative", + "name" : "FromNarrative", + "title" : "Narrative Conformance Statements", + "status" : "active", + "experimental" : false, + "description" : "Conformance statements found throughout the narrative of the IG consolidated into this computable resource for traceability purposes" +} \ No newline at end of file diff --git a/_updatePublisher.bat b/_updatePublisher.bat index 67aebf5..d4e1b7d 100644 --- a/_updatePublisher.bat +++ b/_updatePublisher.bat @@ -8,6 +8,8 @@ SET input_cache_path=%CD%\input-cache\ SET skipPrompts=false SET scriptdlroot=https://raw.githubusercontent.com/HL7/ig-publisher-scripts/main +SET build_bat_url=%scriptdlroot%/_build.bat +SET build_sh_url=%scriptdlroot%/_build.sh SET update_bat_url=%scriptdlroot%/_updatePublisher.bat SET gen_bat_url=%scriptdlroot%/_genonce.bat SET gencont_bat_url=%scriptdlroot%/_gencontinuous.bat @@ -20,7 +22,8 @@ IF "%~1"=="/f" SET skipPrompts=y ECHO. ECHO Checking internet connection... -PING tx.fhir.org -4 -n 1 -w 1000 | FINDSTR TTL && GOTO isonline +powershell -Command "try { $r=[System.Net.WebRequest]::Create('https://tx.fhir.org/r4/metadata'); $r.Timeout=4000; $r.GetResponse().Close(); exit 0 } catch { exit 1 }" +IF %ERRORLEVEL% EQU 0 GOTO isonline ECHO We're offline, nothing to do... GOTO end @@ -69,6 +72,7 @@ IF DEFINED FORCE ( IF "%skipPrompts%"=="y" ( SET create=Y ) ELSE ( + ECHO Will place publisher jar here: %input_cache_path%%publisher_jar% SET /p create="Ok? (Y/N) " ) IF /I "%create%"=="Y" ( @@ -211,6 +215,16 @@ goto end start copy /y "_updatePublisher.new.bat" "_updatePublisher.bat" ^&^& del "_updatePublisher.new.bat" ^&^& exit +:dl_script_7 +ECHO Updating _build.bat +call POWERSHELL -command if ('System.Net.WebClient' -as [type]) {(new-object System.Net.WebClient).DownloadFile(\"%build_bat_url%\",\"_build.new.bat\") } else { Invoke-WebRequest -Uri "%update_bat_url%" -Outfile "_build.new.bat" } +if %ERRORLEVEL% == 0 goto upd_script_6 +echo "Errors encountered during download: %errorlevel%" +goto end +:upd_script_6 +start copy /y "_build.new.bat" "_build.bat" ^&^& del "_build.new.bat" ^&^& exit + + :end diff --git a/_updatePublisher.sh b/_updatePublisher.sh index 0f9ecbe..6a97fe0 100755 --- a/_updatePublisher.sh +++ b/_updatePublisher.sh @@ -12,6 +12,8 @@ gencont_bat_url=$scriptdlroot/_gencontinuous.bat gencont_sh_url=$scriptdlroot/_gencontinuous.sh gen_sh_url=$scriptdlroot/_genonce.sh update_sh_url=$scriptdlroot/_updatePublisher.sh +build_sh_url=$scriptdlroot/_build.sh +build_bat_url=$scriptdlroot/_build.bat skipPrompts=false FORCE=false @@ -103,6 +105,16 @@ if [[ $skipPrompts != true ]]; then if [[ $skipPrompts == true ]] || [[ $response =~ ^[yY].*$ ]]; then echo "Downloading most recent scripts " + curl -L $build_bat_url -o /tmp/_build.new + cp /tmp/_build.new _build.bat + rm /tmp/_build.new + + + curl -L $build_sh_url -o /tmp/_build.new + cp /tmp/_build.new _build.sh + chmod +x _build.sh + rm /tmp/_build.new + curl -L $update_bat_url -o /tmp/_updatePublisher.new cp /tmp/_updatePublisher.new _updatePublisher.bat rm /tmp/_updatePublisher.new @@ -129,4 +141,4 @@ if [[ $skipPrompts == true ]] || [[ $response =~ ^[yY].*$ ]]; then cp /tmp/_updatePublisher.new _updatePublisher.sh chmod +x _updatePublisher.sh rm /tmp/_updatePublisher.new -fi +fi \ No newline at end of file diff --git a/input/fsh/Aliases.fsh b/input/fsh/Aliases.fsh index d50f128..02d98e4 100644 --- a/input/fsh/Aliases.fsh +++ b/input/fsh/Aliases.fsh @@ -1,8 +1,8 @@ Alias: SCT = http://snomed.info/sct Alias: UCUM = http://unitsofmeasure.org Alias: LOINC = http://loinc.org -Alias: CPT = http://terminology.hl7.org/5.0.0/CodeSystem-CPT.html -Alias: ICD10 = http://hl7.org/fhir/sid/icd-10 +Alias: CPT = http://www.ama-assn.org/go/cpt +Alias: ICD10 = http://hl7.org/fhir/sid/icd-10-cm Alias: HL7V2 = http://terminology.hl7.org/CodeSystem/v2-0203 Alias: FHIRObservation = http://terminology.hl7.org/CodeSystem/observation-category @@ -16,8 +16,10 @@ Alias: FHIREndpointStatus = http://hl7.org/fhir/endpoint-status Alias: FHIRDiagnosticReportStatus = http://hl7.org/fhir/diagnostic-report-status Alias: FHIRDiagnosticService = http://terminology.hl7.org/CodeSystem/v2-0074 Alias: FHIRNarrativeStatus = https://hl7.org/fhir/R5/codesystem-narrative-status.html -Alias: FHIRConditionVerificationstatus = http://terminology.hl7.org/5.1.0/CodeSystem-condition-ver-status.html Alias: FHIRProvenanceSignatureType = http://uri.etsi.org/01903/v1.2.2 +Alias: FHIRConditionClinical = http://terminology.hl7.org/CodeSystem/condition-clinical +Alias: FHIRConditionVerStatus = http://terminology.hl7.org/CodeSystem/condition-ver-status +Alias: FHIRConditionCategory = http://terminology.hl7.org/CodeSystem/condition-category Alias: DICOM = http://dicom.nema.org/resources/ontology/DCM Alias: DICOMUID = urn:dicom:uid diff --git a/input/fsh/Attachment.fsh b/input/fsh/Attachment.fsh index dc96556..f61d6e6 100644 --- a/input/fsh/Attachment.fsh +++ b/input/fsh/Attachment.fsh @@ -1,5 +1,5 @@ // Invariant Invariant: IDRAttachmentInvariant -Description: "Either data or url SHALL be present" +Description: "Either data or url SHALL be present for any attachment (e.g. in DiagnosticReport)." Expression: "data.exists() or url.exists()" Severity: #error \ No newline at end of file diff --git a/input/fsh/Communication.fsh b/input/fsh/Communication.fsh index 5b73473..49a47e1 100644 --- a/input/fsh/Communication.fsh +++ b/input/fsh/Communication.fsh @@ -1,29 +1,72 @@ Profile: IDRCommunication Parent: Communication Id: idr-communication -Title: "Communications for Imaging Diagnostic Reports" -Description: "Communications for Imaging Diagnostic Reports." +Title: "IDR Report Communication" +Description: "Communication of impressions, critical results and/or actionable findings in Imaging Diagnostic Reports." -* text MS +* text 1..1 MS +* text ^definition = """ +A summary sentence describing the communication, as currently appears in report narratives. +""" + +* basedOn ^comment = """ +This is often absent unless there was a specific request for the communication that can be referenced. See communication.reason for communications triggered by specific impression findings. +""" * partOf 1..1 MS * partOf only Reference(ImagingDiagnosticReport) +* partOf ^comment = "The current diagnostic report, which provides the context of the communication" + +* status ^comment = """ +Should be COMPLETED in many cases. When documenting attempted communications, the status might have another value. + +Communication resources where the .status is not COMPLETED may trigger subsequent follow-up workflows, but the management of such follow-up is not reflected in the diagnostic report. + +In some reporting workflows, such communications may be included in an Addendum to the report (e.g. when the report is distributed prior to the communication being successfully completed). +""" + +* medium MS +* medium ^comment = """ +For imaging, the value will typically be PHONE, or in the case of leaving a voicemail message, DICTATE. +""" * subject 1..1 MS -* subject only Reference(IDRPatient) +* subject only Reference(Patient) * topic MS - -* reason MS -* reason only CodeableReference(IDRImpressionCondition or IDRRecommendationServiceRequest) +* topic ^comment = """ +May contain the code for "summary-report". Sites may wish to use a code for critical findings. +""" * about MS * about only Reference(IDRImpressionCondition or IDRRecommendationServiceRequest) +* about ^comment = """ +May reference any or all of the specific impression Conditions or recommendation ServiceRequests discussed during the communication if such information is made available to the encoding system. +""" -* medium MS +* encounter ^comment = """ +Should either reference the encounter for the imaging procedure, or be absent. +""" + +* sent 1..1 MS + +* received MS +* received ^comment = """ +For phone communications, this value will typically be the same time as Communication.sent. In the case of leaving a message, this will likely be be absent since it won't be known and the resource is not expected to be updated. +""" * sender MS +* sender ^comment = """ +For imaging, the value should be the imaging clinician in most cases but may be their staff. +""" * recipient MS +* recipient ^comment = """ +For imaging, the value should be the patient or the referring clinician in most cases, but may be their staff. +""" -* sent 1..1 MS \ No newline at end of file +* reason MS +* reason only CodeableReference(IDRImpressionCondition or IDRRecommendationServiceRequest) +* reason ^comment = """ +May reference one or more of the specific impression Conditions or recommendation ServiceRequests that prompted the communication. +""" diff --git a/input/fsh/Condition.fsh b/input/fsh/Condition.fsh index b90a419..03d7eb4 100644 --- a/input/fsh/Condition.fsh +++ b/input/fsh/Condition.fsh @@ -1,8 +1,9 @@ +//TODOQ Can drop this first one? Or are we mandating the text for assembling History text Profile: IDRPatientHistoryCondition Parent: Condition Id: idr-patient-history-condition -Title: "Past diagnosis of patient in Imaging Diagnostic Report" -Description: "A past diagnosis of a patient in an Imaging Diagnostic Report." +Title: "IDR Patient History Condition" +Description: "A past diagnosis of a patient in an imaging report." * text MS @@ -10,69 +11,106 @@ Description: "A past diagnosis of a patient in an Imaging Diagnostic Report." Profile: IDRImpressionCondition Parent: Condition Id: idr-impression-condition -Title: "Impression as Condition" -Description: "An impression as a condition in imaging report." +Title: "IDR Report Impression Condition" +Description: "A condition appearing in the impression of an imaging report." * text MS * category 1..1 MS +// JIRA FHIR-48358 and UP-635 are adding the "diagnostic-report-impression" code to R6. WIP 2025.08.01 +// TODOQ If we want to fix it to "diagnostic-report-impression" is VS the right mechanism? * category from IDRImpressionConditionCategoryVS (required) * verificationStatus 1..1 MS +* verificationStatus ^comment = """ +Typical values will be confirmed, differential, provisional, unconfirmed, and refuted. + +\"confirmed\" would not be used unless the imaging report is the definitive source of such a diagnosis. + +\"refuted\", per , is used for subsequent disproof of a previously asserted condition so it would not be used unless the condition was previously asserted and the radiology report is negative and is definitive for such an assertion. Other negative assertions are handled as observations. +""" * code 1..1 MS +* code ^comment = """ +Codes may be drawn from SNOMED or similar coding system. +""" * severity MS +* severity ^comment = """ +Note 1. Severity does not map directly to patient risk. A mild stroke might present a greater risk than a severe ingrown toenail. +""" * stage MS - -* bodySite 1..1 MS - -* participant 1..* MS +* stage ^comment = """ +This typically depends on the condition having formal (often disease-specific) staging concepts. The imaging clinician might not always assess the stage. +""" + +// JIRA FHIR-50859 for ImagingStudy positioningset up use of BodyStructure encoding not bodySite. Variability increases implementation and testing complexity +* bodySite 0..* +* bodySite ^comment = """ +Should not be present. R6 specifies not to use bodySite when bodyStructure is present. This IG specifies usage of bodyStructure. +""" + +* bodyStructure 0..1 MS +/* TOAddR6toR4 +* extension contains AddR6toR4ConditionBodyStructure named bodyStructure 0..1 MS +*/ +* bodyStructure ^comment = """ +The BodyStructure.includedStructure.structure may contain codes drawn from SNOMED or similar coding system. BodyStructure.laterality shall record laterality if the bodyStructure is a paired structure. + +Note: When a condition spans multiple structures, .includedStructure may include multiple items. +""" +// TODOQ TCQ should we include guidance on when to use fine grained/pre-coordinated structure codes vs the .qualifier element? + +/* TOAddR6toR5 Note: In R4, not R5, back in R6. Need extension for implementers? */ +* asserter 1..1 MS +* asserter ^comment = "In an imaging report, this is the imaging clinician." + +* clinicalStatus ^comment = """ +This element is required to be present by the Condition resource. In diagnostic reports, the clinicalStatus will frequently be \"unknown\", but the other defined values may be used when appropriate. +""" * evidence MS - -* extension contains IDRImpressionLaterality named laterality 0..1 MS +* evidence ^comment = """ +May contain a reference to the DiagnosticReport and/or references to Observation resources in the Findings and/or Impression sections, or references to other information elsewhere that contributed to this impression item. +""" * extension contains IDRImpressionLikelihood named likelihood 0..1 MS -* extension contains IDRImpressionOrder named order 1..1 MS - * extension contains IDRImpressionActionable named actionable 0..1 MS -* extension contains IDRImpressionIncidental named incidental 0..1 MS - -Extension: IDRImpressionLaterality -Title: "IDR BodySite Laterality in Impression." -Id: idrImpressionLaterality -Description: "Laterality of impression" -Context: Condition -* value[x] only CodeableConcept - Extension: IDRImpressionLikelihood -Title: "IDR BodySite Likelihood in Impression." +Title: "IDR Impression Condition Likelihood." Id: idrImpressionLikelihood -Description: "likelihood of impression" +Description: "likelihood of condition assertion" Context: Condition * value[x] only CodeableConcept -Extension: IDRImpressionOrder -Title: "Impression Order." -Id: IDRImpressionOrder -Description: "Order in impression" -Context: Condition -* value[x] only positiveInt +/* TODO +- Condition.likelihood shall record the likelihood of the + condition, if expressed by the imaging clinician. (See Open Issue + about adoption of a coding system) + +Note: "Consistent with" in the narrative form of an impression typically +implies strong imaging support for an existing (tentative) diagnosis in +place beforehand. Most other impressions represent conditions put +forward by the imaging clinician. If the Condition resource for the +existing diagnosis is known, consider referencing that instance and +adding information to Condition.evidence. +*/ Extension: IDRImpressionActionable -Title: "Actionable indication in Impression." +Title: "IDR Actionable Condition" Id: idrImpressionActionable Description: "Actionable indication in impression." Context: Condition * value[x] only CodeableConcept -Extension: IDRImpressionIncidental -Title: "Incidental indication of Impression." -Id: idrImpressionIncidental -Description: "Incidental indication of impression." +/* TOAddR6toR4 +Extension: AddR6toR4ConditionBodyStructure +Title: "(AddR6toR4) Condition.bodyStructure" +Id: idrConditionBodyStructure +Description: "Body Structure where the condition occurs." Context: Condition -* value[x] only boolean \ No newline at end of file +* value[x] only Reference(BodyStructure) +*/ \ No newline at end of file diff --git a/input/fsh/DiagnosticReport.fsh b/input/fsh/DiagnosticReport.fsh index 7b5631c..0a55710 100644 --- a/input/fsh/DiagnosticReport.fsh +++ b/input/fsh/DiagnosticReport.fsh @@ -1,13 +1,39 @@ Profile: ImagingDiagnosticReport Parent: DiagnosticReport Id: imaging-diagnosticreport -Title: "Imaging Diagnostic Report" -Description: "IHE Imaging Diagnostic Report (IDR) profile on DiagnosticReport" +Title: "IDR Imaging DiagnosticReport" +Description: "IHE Imaging Diagnostic Report (IDR) Profile of DiagnosticReport" +* ^purpose = """ +Each instance of an imaging diagnostic report shall be encoded as a single DiagnosticReport resource. -* text 1..1 MS +Note: A subsequent addendum would result in an additional DiagnosticReport instance, however that workflow is not yet fully documented in this Profile. +""" +//TODO2 Review and be intentional about which elements are MS, and highlight in the narrative for implementers +//TODO2 Review for SHALL in comments and decide how to migrate into normative mechanisms +//TODO2 Leverage the Versioning Package as described in ChatGPT and tag things as AddR5toF4, AddR6toR4, or IDR +//TODO2 determine what elements should be Summary - review FHIR guidance - don't include things that are bulky and not always used + +// TODO2 figure out how to get tooling to autogenerate examples without triggering complaints if its 1..1 +* text 0..1 MS +* text ^short = "Fully-rendered, human-readable report" +* text ^definition = "" + +//Added Note 4 to mirror the Accession # solution worked out for ImagingStudy.basedOn see https://jira.hl7.org/browse/FHIR-49675 +//TODO2 Update Note 5 that This accession number is expected to match those in the ImagingStudy and ServiceRequest. In some urgent or encounter-based scenarios, a ServiceRequest might not exist at the time of reporting. +//TODO2 Note: Some workflows may involve the creation of local accession numbers in the imaging workflow which are later replaced by accession numbers assigned in enterprise systems. When such replacement takes place, it is important to consider the potential presence of the local accession number in the narrative text, or in rendered PDF documents, as well as in resource attributes. -// May reference no ServiceRequest for other -ologies in enterprise imaging * basedOn 0..* MS +* basedOn ^comment = """ +Note 1. For result resources like DiagnosticReport, .basedOn references the authorizing request being fulfilled; i.e. the order, not the input data. So DiagnosticReport.basedOn references the imaging ServiceRequest, not the ImagingStudy. + +Note 2. Report Creators do not create orders. It is expected that an appropriate ServiceRequest resource will exist which may have been created by another system more integrated with order management. The hospital may originate orders as ServiceRequest resources, or may create ServiceRequests based on HL7 v2 ORM or OMG messages. In either case, reporting systems are not the Source of Truth for order management; it would be disruptive for them to directly create/modify order resources. + +Note 3. \"Group Cases\": While one report typically corresponds to one order (ServiceRequest) comprised of one study, some reports do cover multiple orders. A radiologist may satisfy multiple ServiceRequests in a single report. Depending on site preferences related to billing and workflow, systems should be prepared to handle this as a single report basedOn multiple ServiceRequests, or as multiple copies of the same report, each basedOn a different ServiceRequest. + +Note 4. If the DiagnosticReport is associated with an Accession Number, this field should include a reference to that value in the form: identifier.value = (Accession Number Value) identifier.type = ACSN. A reference value pointing to a ServiceRequest resource is allowed but is not required. + +Note 5. DiagnosticReport.basedOn may be empty in some scenarios, e.g. when emergency imaging is performed and an order has not been backfilled before reporting. +""" * basedOn ^slicing.discriminator.type = #type * basedOn ^slicing.discriminator.path = resolve() @@ -16,33 +42,53 @@ Description: "IHE Imaging Diagnostic Report (IDR) profile on DiagnosticReport * basedOn ^slicing.ordered = false * basedOn contains serviceRequest 0..* -* basedOn[serviceRequest] only Reference(ImagingServiceRequest) -* basedOn[serviceRequest] ^short = "The order for imaging." +* basedOn[serviceRequest] only Reference(IDRImagingServiceRequest) +* basedOn[serviceRequest] ^short = "The imaging order" +* basedOn[serviceRequest] ^definition = "The order for the imaging procedure being reported." -* status from IDRDiagnosticReportStatusVS +* status ^comment = """ +Values of preliminary and final shall be used when their conventional meaning for imaging reports applies. A value of registered state be used while the report is being composed during the interpretation process. For addenda, a value of amended shall be used. . +Note: Other FHIR status values such as modified, corrected, or appended are not profiled here. They may be addressed in a reporting workflow profile. +""" + +//TODOQ TCQ Consider if we should add a VS as recommended * category 1..* MS +* category ^short = "Diagnostic Service" +* category ^definition = "A code for the diagnostic service that performed the imaging study" +* category ^comment = """ +It is recommended that this code focus on the service/department, since the modality is already reflected in DiagnosticReport.code. + +Potential codes may be drawn from DICOM [PS3.16 CID 7030](https://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7030.html) \"Institutional Department/Unit/Service\" and the HL7 terminology code set referenced in FHIR. + +This value may be copied from the ServiceRequest.category that the report is basedOn. +""" + +//TODO2 The HL7 preferred binding to LOINC Diagnostic Report Codes needs refinement. It points to a mega-list +* code ^comment = """ +Imaging report titles are frequently site specific, but commonly communicate the modality, body part, and/or clinical focus of the performed imaging procedure. + +Note 1. Since report titles often mirror the name of the ordered imaging procedure, the codes from the RSNA Radlex Playbook provide a useful example codeset. ([Search LOINC](https://search.loinc.org) for \“playbook\”) +""" + // Shall reference on Patient * subject 1..1 MS * subject only Reference(IDRPatient) * subject ^short = "The imaged patient" +* subject ^comment = """ +Note 1. Report Creators do not create patient resources. It is expected that an appropriate Patient resource will exist, even if only a John Doe, created by another system more integrated with patient management. Imaging systems are not the Source of Truth for patient demographics and management; it would be disruptive for them to directly create/modify patient resources. If a patient reference is a pre-requisite to publish imaging DiagnosticReport resources, the local infrastructure will arrange for appropriate Patient resources for the Report Creator to use. +""" * issued 1..1 -* issued ^short = "DateTime that this diagnostic report is published." - -// Deprecated attributes in IDR -* note 0..0 -* composition 0..0 -* media 0..0 +* issued ^short = "DateTime report was published." -// Ambiguious in case of imaging report. So exclude it. -* encounter 0..0 +// Ambiguious in case of imaging report. So exclude it? +// JIRA FHIR-48767 [Applied] fixes description to highlight this is the encounter during which the data/sample being reported was obtained. Could drop this revised Definition text? +* encounter 0..1 * encounter ^definition = """ -For imaging procedure encounter, DiagnosticReport.procedure.encounter. -For ordering encounter, DiagnosticReport.basedOn[ServiceRequest].encounter. - -DiagnosticReport.encounter is redundant and ambiguious. So it is excluded. +If present, will reflect the encounter of the imaging procedure being reported (which may also be found in DiagnosticReport.procedure.encounter.) +To find the encounter during with the order for the imaging procedure was placed, see DiagnosticReport.basedOn[ServiceRequest].encounter. """ // At least one performer is an Organization @@ -56,75 +102,175 @@ DiagnosticReport.encounter is redundant and ambiguious. So it is excluded. * performer contains organization 1..* * performer[organization] only Reference(Organization) +* performer ^comment = """ +The organization (which may be a diagnostic service) responsible for the report is captured here. The specific clinician is captured in resultsInterpreter. +""" // At least one resultsInterpreter is a Practitioner or PractitionerRole * resultsInterpreter 1..* * resultsInterpreter only Reference(Practitioner or PractitionerRole) -* resultsInterpreter ^short = "Primary intepreter of results" -* resultsInterpreter ^definition = "Primary intepreter of results" +* resultsInterpreter ^comment = """ +This is imaging clinician(s) the study is reported by. + +Additional report authors may also be referenced. PractitionerRole resources may be used to record participants such as residents, collaborating clinicians and the role they played. +""" * result 0..* MS * result only Reference(IDRObservation) * result ^short = "Findings" * result ^definition = """ -Detailed description of the findings on the imaging study. The findings should be described in a clear and concise manner, -using standardized anatomic, pathologic, and radiologic terminology whenever possible. +Detailed description of the findings on the imaging study. The findings should be described in a clear and concise manner, using standardized anatomic, pathologic, and radiologic terminology whenever possible. +""" + +//Permit but discourage usage of .note +* note ^short = "See Detailed Description Comments" +* note ^comment = """ +In imaging diagnostic reports, statements about significant, unexpected or unreliable result values appear as needed in the Findings, Conclusions, or Procedure, not in .note. Other imaging usage was not identified. """ +// JIRA FHIR-49614 [Applied in R6] adds .procedure +// TODO JIRA to fix current R6-ballot3 comment "This is a summary of the report, not a list of results." +* procedure ^comment = """ + +""" + + // Shall include at least one referenced study * study 1..* MS -* study only Reference(ImagingStudyInImagingReport) -* study ^short = "Study subject to this report" -* study ^definition = "Study subject to this report. Note: Any associated study (e.g. comparison studies) used during reporting should be tracked in the associatedStudy extension." +* study only Reference(IDRImagingStudy) +* study ^short = "Reported Imaging Study" +* study ^definition = "Study interpreted by the imaging clinician in this report." +* study ^comment = """ +The ImagingStudy for the study being read shall be referenced unless no such ImagingStudy resource exists. + +Note 1. Report Creators do not typically create ImagingStudy resources. It is expected that an appropriate ImagingStudy resource will exist, created by another system more integrated with image management, such as the PACS, or the VNA, or the EMR in response to messaging from the PACS or VNA. Report Creators are not the Source of Truth for imaging study management. In the absence of an ImagingStudy, the ServiceRequest and Accession Number will serve to provide basic linkages between the images and the report. + +Note 2. Studies available for comparison during reporting are tracked in the comparison element, not the study element. +""" -* conclusion MS +// Media are intended for auxilliary use. Reported images are referenced in .study +* media ^short = "Auxilliary media" +* media ^comment = """ +Graphical elements such as charts and icons that appear in the presentedForm of the report may go here if they cannot be included inline in the format used (PDF, etc.). -* extension contains IDRComparisonStudiesExt named comparison 0..* MS +The interpreted study is referenced from the .study element, not here. Those study images may be accessible as RESTful resources via DICOMweb (which includes parameterized renderings using the /rendered DICOMweb endpoint to adjust windowing and other parameters). Selected parts or points of those images are encoded as ImagingSelection resources. Comparison studies are referenced from the .comparison element. +""" -* extension contains IDRPatientHistoryExt named patientHistory 0..* MS -* extension[patientHistory] ^short = "Patient history items selected by radiologist" -* extension[patientHistory] ^definition = """ -May have originally been extracted from the medical record by imaging staff, -automated tools, or by the radiologists themselves. +// Permitted but not required. Supports supplemental composition. +* composition 0..1 +* composition ^short = "Additional compositions" +* composition ^comment = """ +Composition may be included to supplement .text and .presentedForm with additional presentations and compositions of the report content to meet the preferences of different readers, tasks, or site guidelines. """ -* extension contains IDRImagingProcedureExt named procedure 0..* MS -* extension[procedure] ^short = "Imaging procedure" -* extension[procedure] ^definition = """ -Imaging procedure used to acquire the study. +* conclusion MS +* conclusion ^short = "Impression / Conclusion" +* conclusion ^definition = "" +* conclusion ^comment = """ +Note 1. In the presentedForm (PDF, HTML, etc.), section text titled Impression frequently contains not just impressions, but also recommendations, and communications. IDR profiles usage of specific encodings for those in the recommendation and communication elements. """ -* extension contains IDRImpressionExt named impression 1..* MS -* extension[impression] ^short = "Impression" -* extension[impression] ^definition = """ -Impression in the imaging report. +/* TODOQ Change type of conclusionCode to match R6; Grrr may have to make a conclusionCodeR extension and ask around? +* conclusionCode MS +* conclusionCode only CodeableReference +*/ +* conclusionCode ^short = "supplemented by conclusionCodeR" +* conclusionCode ^definition = "" +* conclusionCode ^comment = """ +R6 makes .conclusionCode a CodeableReference to allow a Condition (or Observation) to be a coded conclusion. + +Since I haven't figured out how to do that in a Profile (it is an expansion, not a constraint on the underlying resource) I have created a sister element .conclusionCodeR so I can continue building sample objects and resolving brittle build issues. """ -* extension contains IDRRecommendationExt named recommendation 0..* MS -* extension[recommendation] ^short = "Recommendations" -* extension[recommendation] ^definition = """ -Recommendations a radiologist provides in the report for possible follow up actions. +* presentedForm obeys IDRAttachmentInvariant +* presentedForm.contentType 1..1 MS +* presentedForm.size 1..1 MS +* presentedForm.hash 1..1 MS + +/* TODO Profile IDRImpressionCondition resource +Note 1. Condition is used here as a proxy for a diagnosis or problem that is +not yet determined, per its FHIR documentation. +*/ + +//TODO Look in sushi-config.yaml and have a dependency section that "pulls in" the relevant extensions + +// TODO revert these back to R6 specs and do the AddR6toR4 extension package as a bulk thing once its clear how +// TOAddR6toR4 Add R6 .comparison to R4 +// JIRA FHIR-48389 Add comparison [Triaged - Resolved] BUT not applied +* extension contains AddR6toR4DiagnosticReportComparison named comparison 0..* MS +* extension[comparison] ^short = "Relevant prior exams" +* extension[comparison] ^definition = "Prior imaging studies that were considered relevant to the current study and made available to the imaging clinician at the time of reporting." +* extension[comparison] ^comment = """ +The primary study being reported is referenced from the study element. """ -* extension contains IDRCommunicationExt named communication 0..* MS -* extension[communication] ^short = "Communications with other care providers" -* extension[communication] ^definition = """ -Communications captures what communications have been made with other care providers. +// TOAddR6toR4 Add R6 .conclusionCode(R) as CodeableReference to R4 +// JIRA FHIR-48392 [Applied] Made conclusionCode a codeableReference +// This is a patch. Can't profile .conclusionCode from CodeableConcept to CodeableReference. So instead adding a sister element to hold the Reference which is the current focus +* extension contains AddR6toR4DiagnosticReportConclusionCodeReference named conclusionCodeR 0..* MS +* extension[conclusionCodeR] ^short = "Impression / Conclusion (coded)" +* extension[conclusionCodeR] ^definition = "" +* extension[conclusionCodeR] ^comment = """ +A .conclusionCode item, being a CodeableReference, may contain an individual code instead of a reference when a code exists that encompasses the conclusion or impression. + +An impression drawn from a \*-RADS System, such as BI-RADS TOLINK, is encoded as a .conclusionCode item containing the corresponding code. For example, (397143007, SCT, \"Mammography assessment (Category 3) - Probably benign finding, short interval follow-up\"). + +Note 1. \*-RADS codes correspond to the result of a composite assessment, and the conclusion may represent a point on a diagnostic pathway, which encompasses both a differential diagnosis and protocolized follow-up actions. """ -* extension contains IDRSignatureExt named approval 0..* MS -* extension[approval] ^short = "Attestation" -* extension[approval] ^definition = """ -Attestation by a radiologist that the report content is correct. +// Add R6 .recommendation to R4 +// JIRA FHIR-45290 [Applied] added .recommendation as a codeableReference +* extension contains AddR6toR4DiagnosticReportRecommendation named recommendation 0..* MS +* extension[recommendation] ^short = "Recommendations based on findings and interpretations" +* extension[recommendation] ^definition = "Proposed follow-up actions based on the findings and interpretations of the diagnostic test for which this report is the subject." + +// * communication 0..* MS +// Add R6 .communication to R4 +// JIRA FHIR-48390 [Applied in R6] added .communication as a Reference +* extension contains AddR6toR4DiagnosticReportCommunication named communication 0..* MS +* extension[communication] ^short = "Communication initiated during the reporting process" +* extension[communication] ^definition = "Communications 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." +* extension[communication] ^comment = """ +These communications are limited to those 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. Communications that follow publication of the report (e.g. between the referring physician and the patient or a subsequent specialist) are not referenced here. """ +// JIRA FHIR-48391 to cover patient history [Triaged] +* extension contains IDRPatientHistoryExt named patientHistory 0..* MS +* extension[patientHistory] ^short = "Patient history items selected by radiologist" +* extension[patientHistory] ^definition = "May have originally been extracted from the medical record by imaging staff, automated tools, or by the radiologists themselves." + +// JIRA FHIR-49614 [Applied in R6] added .procedure +* extension contains IDRImagingProcedureExt named procedure 0..* MS +* extension[procedure] ^short = "Imaging procedure" +* extension[procedure] ^definition = "Imaging procedure used to acquire the study." + +Extension: AddR6toR4DiagnosticReportComparison +Title: "(AddR6toR4) DiagnosticReport.comparison" +Id: idrDiagnosticReportComparison +Description: "Relevant prior exams" +Context: DiagnosticReport +* value[x] only Reference(IDRImagingStudy) + +Extension: AddR6toR4DiagnosticReportConclusionCodeReference +Title: "(AddR6toR4) DiagnosticReport.conclusionCode as CodeableReference" +Id: idrDiagnosticReportConclusionCodeReference +Description: "Coded Conclusions about Conditions and Observations" +Context: DiagnosticReport +* value[x] only Reference(IDRImpressionCondition or IDRObservation) + +Extension: AddR6toR4DiagnosticReportRecommendation +Title: "(AddR6toR4) DiagnosticReport.recommendation" +Id: idrDiagnosticReportRecommendation +Description: "Recommendations based on findings and interpretations" +Context: DiagnosticReport +* value[x] only Reference(IDRRecommendationServiceRequest) -Extension: IDRComparisonStudiesExt -Title: "IDR DiagnosticReport Comparison Study" -Id: idrComparisonStudy -Description: "Studies used for comparison in part of diagnostic reporting" +Extension: AddR6toR4DiagnosticReportCommunication +Title: "(AddR6toR4) DiagnosticReport.communication" +Id: idrDiagnosticReportCommunication +Description: "Communication initiated during the reporting process." Context: DiagnosticReport -* value[x] only Reference(IDRComparisonStudy) +* value[x] only Reference(IDRCommunication) Extension: IDRPatientHistoryExt Title: "IDR Patient History" @@ -138,32 +284,4 @@ Title: "IDR Imaging Procedure" Id: idrImagingProcedure Description: "Imaging procedure used for the imaging acquisition" Context: DiagnosticReport -* value[x] only Reference(IDRProcedure) - -Extension: IDRImpressionExt -Title: "IDR Impression" -Id: idrImpression -Description: "Impression in the imaging report" -Context: DiagnosticReport -* value[x] only Reference(IDRImpressionCondition or IDRObservation) - -Extension: IDRRecommendationExt -Title: "IDR Recommendation" -Id: idrRecommendation -Description: "Recommendations for any follow up actions" -Context: DiagnosticReport -* value[x] only Reference(IDRRecommendationServiceRequest) - -Extension: IDRCommunicationExt -Title: "IDR Communication" -Id: idrCommunication -Description: "Communications captures what communications have been made with other care providers" -Context: DiagnosticReport -* value[x] only Reference(IDRCommunication) - -Extension: IDRSignatureExt -Title: "IDR Signature" -Id: idrSignature -Description: "Report signature" -Context: DiagnosticReport -* value[x] only Reference(IDRSignatureProvenance) \ No newline at end of file +* value[x] only Reference(IDRImagingProcedure) \ No newline at end of file diff --git a/input/fsh/Endpoint.fsh b/input/fsh/Endpoint.fsh index d2ae65a..077114d 100644 --- a/input/fsh/Endpoint.fsh +++ b/input/fsh/Endpoint.fsh @@ -16,9 +16,13 @@ Description: "Codes representing the applicable endpoint connectionType to retri * FHIREndpoint#ihe-iid "IHE IDD" * FHIREndpoint#dicom-wado-rs "DICOM WADO-RS" +* ^experimental = false + ValueSet: ImagingStudyEndpointPayloadTypeVS Id: imaging-study-endpoint-payloadtype-vs Title: "Imaging Study Endpoint PayloadType Value Set" Description: "Codes representing the applicable endpoint payloadType to retrieve a study." -* DICOM#113014 "Study" \ No newline at end of file +* DICOM#113014 "Study" + +* ^experimental = false \ No newline at end of file diff --git a/input/fsh/FamilyMemberHistory.fsh b/input/fsh/FamilyMemberHistory.fsh index bf43994..b95e718 100644 --- a/input/fsh/FamilyMemberHistory.fsh +++ b/input/fsh/FamilyMemberHistory.fsh @@ -1,7 +1,7 @@ Profile: IDRPatientHistoryFamilyMemberHistory Parent: FamilyMemberHistory Id: idr-patient-history-family-member-history -Title: "Family member medical history of patient in Imaging Diagnostic Report" -Description: "Perons's relationship to the patient, along with the person's demographics, known conditions and procedures." +Title: "IDR FamilyMemberHistory" +Description: "Family member medical history of patient in Imaging Diagnostic Report" * text MS \ No newline at end of file diff --git a/input/fsh/ImagingSelection.fsh b/input/fsh/ImagingSelection.fsh index dfa3b37..cd25934 100644 --- a/input/fsh/ImagingSelection.fsh +++ b/input/fsh/ImagingSelection.fsh @@ -1,8 +1,8 @@ Profile: ReportKeyImages Parent: ImagingSelection Id: idr-report-key-images -Title: "ImagingSelection for key images in an imaging diagnostic report" -Description: "IHE IDR ImagingSelection to be used to capture key images associated with an Observation" +Title: "IDR ImagingSelection" +Description: "ImagingSelection for key images associated with an Observation" * status = #available diff --git a/input/fsh/ImagingStudy.fsh b/input/fsh/ImagingStudy.fsh index 4074789..3e4d271 100644 --- a/input/fsh/ImagingStudy.fsh +++ b/input/fsh/ImagingStudy.fsh @@ -1,22 +1,24 @@ +/* Profile: IDRComparisonStudy -Parent: ImagingStudy +Parent: IDRReportedImagingStudy Id: idr-comparison-study -Title: "Comaprison studies" -Description: "This serves as a library of studies that imaging clinician took into considerations." +Title: "IDR Comparison ImagingStudy" +Description: "ImagingStudy(ies) available to the imaging clinician for comparison during reporting." * text MS +*/ - - -Profile: ImagingStudyInImagingReport +Profile: IDRImagingStudy Parent: ImagingStudy -Id: idr-imaging-study-in-imaging-report +Id: idr-imaging-study Title: "IDR ImagingStudy" -Description: "ImagingStudy that the findings and impressions in an imaging diagnostic report are based on." +Description: "ImagingStudy(ies) being reported or referenced as priors for comparison by the imaging clinician." * text MS // Must have an identifier which is the study instance UID +// TODO Confirm harmonization with R6 ImagingStudy. +// JIRA See also https://jira.hl7.org/browse/FHIR-49675 * identifier 1..* * identifier ^slicing.discriminator.type = #value @@ -35,6 +37,7 @@ Description: "ImagingStudy that the findings and impressions in an imaging di * started 1..1 MS +// TODOQ Kinson - Do we need to keep the following for IDR? And would Endpoint.fsh migrate into examples? E.g. to encode external reports that were received without images? // Must have at least one endpoint at the study level of type IMRStudyEndpoint * endpoint 1..* * endpoint only Reference(ImagingStudyEndpoint) diff --git a/input/fsh/Observation-history.fsh b/input/fsh/Observation-history.fsh index f4decaa..61bd3e1 100644 --- a/input/fsh/Observation-history.fsh +++ b/input/fsh/Observation-history.fsh @@ -1,7 +1,7 @@ Profile: IDRPatientHistoryObservation Parent: Observation Id: idr-patient-history-observation -Title: "Relevant observations of patient" +Title: "IDR Patient History Observation" Description: "Relevant observations from referring physician, nursing notes, past care, and past diagnostics such as patholgy or lab values." * text MS \ No newline at end of file diff --git a/input/fsh/Observation.fsh b/input/fsh/Observation.fsh index 7375906..72655f9 100644 --- a/input/fsh/Observation.fsh +++ b/input/fsh/Observation.fsh @@ -1,8 +1,8 @@ Profile: IDRObservation Parent: Observation Id: idr-observation -Title: "Findings or Impressions in Diagnostic Reports" -Description: "Findings or Impressions in Diagnostic Reports" +Title: "IDR Imaging Observation" +Description: "Findings or impressions in imaging reports" * text MS @@ -16,7 +16,7 @@ Description: "Findings or Impressions in Diagnostic Reports" * basedOn ^slicing.ordered = false * basedOn contains serviceRequest 1..* -* basedOn[serviceRequest] only Reference(ImagingServiceRequest) +* basedOn[serviceRequest] only Reference(IDRImagingServiceRequest) // Shall reference on Patient * subject 1..1 @@ -25,19 +25,19 @@ Description: "Findings or Impressions in Diagnostic Reports" * encounter MS * partOf MS -* partOf only Reference(ImagingStudyInImagingReport) +* partOf only Reference(IDRImagingStudy) // Specify the category to be imaging * category 1..* * category ^slicing.discriminator.type = #value -* category ^slicing.discriminator.path = "coding" +* category ^slicing.discriminator.path = "$this" * category ^slicing.rules = #open * category ^slicing.description = "Slice based on the category.coding" * category ^slicing.ordered = false * category contains imaging 1..1 MS -* category[imaging].coding = FHIRObservation#imaging +* category[imaging] = FHIRObservation#imaging * status MS * status = FHIRObservationStatus#final @@ -55,13 +55,13 @@ Description: "Findings or Impressions in Diagnostic Reports" * derivedFrom ^slicing.ordered = false * derivedFrom contains imagingSelection 0..* -* derivedFrom[imagingSelection] only Reference(ImagingSelection) +* derivedFrom[imagingSelection] only Reference(ReportKeyImages) Profile: IDRObservationSingle Parent: IDRObservation Id: idr-observation-single -Title: "Experimental: Observation with a single value" +Title: "IDR Single Value Observation: Experimental" Description: "An observation that captures a single value" * value[x] 1..1 MS @@ -73,7 +73,7 @@ Description: "An observation that captures a single value" Profile: IDRObservationComponent Parent: IDRObservation Id: idr-observation-component -Title: "Experimental: Observation with a single result consists of multiple components" +Title: "IDR Multi-Component Observation: Experimental" Description: "An observation that captures a single result which consists of multiple components" * value[x] 0..0 @@ -84,7 +84,7 @@ Description: "An observation that captures a single result which consists of Profile: IDRObservationSingleWithComponent Parent: IDRObservation Id: idr-observation-single-with-component -Title: "Experimental: Observation with a single value and component(s)" +Title: "IDR Single Value And Component Observation: Experimental" Description: "An observation that captures a single value with component(s)" * value[x] 1..1 MS @@ -95,7 +95,7 @@ Description: "An observation that captures a single value with component(s)" Profile: IDRObservationComplex Parent: IDRObservation Id: idr-observation-complex -Title: "Experimental: Observation with complex values" +Title: "IDR Complex Values Observation: Experimental" Description: "An observation that captures a complex results, possibly with nested structure." * value[x] MS diff --git a/input/fsh/Procedure.fsh b/input/fsh/Procedure.fsh index b36c788..7b5cd04 100644 --- a/input/fsh/Procedure.fsh +++ b/input/fsh/Procedure.fsh @@ -1,21 +1,34 @@ Profile: IDRPatientHistoryProcedure Parent: Procedure Id: idr-patient-history-procedure -Title: "Past procedure performed on patient in Imaging Diagnostic Report" -Description: "A procedure that was performed on the patient in the past." +Title: "IDR Patient History Procedure" +Description: "A patient history entry describing a past procedure performed on them." * text MS - -Profile: IDRProcedure +Profile: IDRImagingProcedure Parent: Procedure -Id: idr-procedure -Title: "Procedure and material information in Imaging Diagnostic Report" -Description: "A procedure that was performed on the patient." +Id: idr-imaging-procedure +Title: "IDR Reported Imaging Procedure" +Description: "Procedure information, such as technique, materials, and processing, for the imaging procedure being reported." + +* ^purpose = """ +For examples of the content to be encoded, see TOLINK RAD TF-3:B.TODO.Procedure +""" +// TODO2 consider if we should de-emphasize processing (like 3D) since that may have been driven by billing, not clinical? + * text MS * complication MS +* complication ^comment = """ +Condition(s) caused by the procedure, including adverse events and reactions, may be referenced here. + +Note: Events during the imaging Procedure may also result in AllergyIntolerance and/or AdverseEvent resources being added to the patient record, however that is not driven by the diagnostic report and is outside the scope of the IDR profile. +""" -* note MS \ No newline at end of file +* note MS +* note ^comment = """ +Annotations which the Technologist might create to record comments such as patient motion, or other details may be referenced here. This information should be presented or made available to the imaging clinician, but does not directly appear in the report unless dictated/selected by the imaging clinician." +""" \ No newline at end of file diff --git a/input/fsh/Provenance.fsh b/input/fsh/Provenance.fsh deleted file mode 100644 index e67f6b2..0000000 --- a/input/fsh/Provenance.fsh +++ /dev/null @@ -1,13 +0,0 @@ -Profile: IDRSignatureProvenance -Parent: Provenance -Id: idr-signature-provenance -Title: "Signature" -Description: "Signature for Imaging Diagnostic Reports." - -* text MS - -* signature 1..1 MS -* signature.type 1..1 MS -* signature.type = FHIRProvenanceSignatureType#ProofOfapproval -* signature.who only Reference(Practitioner or PractitionerRole) -* signature.onBehalfOf only Reference(Practitioner or PractitionerRole) \ No newline at end of file diff --git a/input/fsh/ServiceRequest.fsh b/input/fsh/ServiceRequest.fsh index c65a58f..c3e0228 100644 --- a/input/fsh/ServiceRequest.fsh +++ b/input/fsh/ServiceRequest.fsh @@ -1,35 +1,61 @@ -Profile: ImagingServiceRequest +Profile: IDRImagingServiceRequest Parent: ServiceRequest -Id: imaging-service-request -Title: "Imaging ServiceRequest" -Description: "Imaging order that this imaging diagnostic report is based on." +Id: idr-imaging-service-request +Title: "IDR Imaging ServiceRequest" +Description: "Imaging order suitable for referencing from an IDR imaging diagnostic report." * text MS -// Must have an identifier which is the accession number +// Must code any accession number(s) as shown to facilitate linkage/searching in unusual scenarios +// This aligns with the ImagingStudy usage described here https://jira.hl7.org/browse/FHIR-49675 * identifier 1..* * identifier ^slicing.discriminator.type = #value -* identifier ^slicing.discriminator.path = "type.coding" +* identifier ^slicing.discriminator.path = "type" * identifier ^slicing.rules = #open * identifier ^slicing.description = "Slice based on the identifier.type.coding" * identifier ^slicing.ordered = false -* identifier contains accession 1..1 MS +* identifier contains accession 0..* MS * identifier[accession].type 1..1 MS -* identifier[accession].type.coding = HL7V2#ACSN +* identifier[accession].type = HL7V2#ACSN * identifier[accession].value 1..1 MS * code 1..1 MS +* code ^short = "Exam type (orderable code)" +* code ^definition = "The \"orderable code\" indicating the type of exam ordered." +* code ^comment = "Some sites may use LOINC Playbook codes, or some other standard. Others will invent local code sets." * intent from ImagingServiceRequestIntentVS (required) * subject only Reference(IDRPatient) * reason MS -* reason only CodeableReference(Condition or Observation) -* reason ^short = "Indications for the imaging study" +* reason ^short = "Indication(s) for the imaging order" +* reason ^comment = """ +Indications might include patient conditions or observations, prior procedures or current medications for followup, family history items, etc. Such resources may increasingly use ICD-10 codes. +Note 1. A Condition referenced as an indication might reasonably have a .verificationStatus of Provisional or Unconfirmed. +""" + +* reason.concept.text MS +* reason.concept.text ^comment = """ +Clinical Questions from the referring physician to the imaging clinician shall be encoded in a ServiceRequest.reason item using the .concept.text element. The presence of clinical questions (and other reasons for exam) are intended to trigger their presentation to the imaging clinician during protocoling and during reporting, and result in text in the body of the diagnostic report that specifically addresses those question(s). + +Note: These questions asked by the requester (referring) and answered by the performer (imaging clinician) at reporting time differ from "ask at order entry questions" (aka AOEs) in lab orders which are answered by the requester (referring physician) in ServiceRequest.supportingInfo at order time to questions asked (out of band) by the performer (lab clinician). +""" +//TODO Should we add a normative requirement somewhere that clinical questions shall be supported? + +* encounter MS +* encounter ^comment = """ +Note 1. While this encounter is the health care event when the imaging was ordered, and Procedure.encounter is the event when the the imaging occurred, those could be the same in the case of encounter-based imaging. Whether a ServiceRequest is created for encounter-based imaging and how it is populated are left for future workflow profiling. +""" + +* orderDetail ^comment = """ +May specify details about how the ordered procedure is to be performed, such as imaging teechnique parameters to use or views to be obtained. Typically, however, such details are left to the imaging department. +""" + +//TODOQ Kinson - what was the motivation for this value set? ValueSet: ImagingServiceRequestIntentVS Id: imaging-servicerequest-intent-vs Title: "Imaging ServiceRequest intent Value Set" @@ -40,13 +66,15 @@ Description: "Codes representing the applicable intent for a ServiceRequest." * FHIRIntent#filler-order "Filler Order" * FHIRIntent#instance-order "Instance Order" +* ^experimental = false + Profile: IDRRecommendationServiceRequest Parent: ServiceRequest Id: idr-recommendation-service-request -Title: "Recommendation" -Description: "Recommendations as ServiceRequest" +Title: "IDR Recommendation ServiceRequest" +Description: "Draft ServiceRequests representing Recommendations from an Imaging Report" * text MS @@ -57,7 +85,10 @@ Description: "Recommendations as ServiceRequest" * reason MS * reason only CodeableReference(IDRImpressionCondition) -* occurrence[x] 1..1 MS +* occurrence[x] MS +* occurrence[x] ^comment = """ +Although not required, the occurence can specify a period of time within which it is recommended that service be performed. This can be helpful to set up triggers for time-appropriate followup reminders. +""" * performerType MS @@ -68,3 +99,5 @@ Title: "Recommendation Imaging ServiceRequest intent Value Set" Description: "Codes representing the recommendation intent for a ServiceRequest." * FHIRIntent#plan "Plan" * FHIRIntent#proposal "Proposal" + +* ^experimental = false diff --git a/input/fsh/capability.fsh b/input/fsh/capability.fsh index 467161d..9d3b097 100644 --- a/input/fsh/capability.fsh +++ b/input/fsh/capability.fsh @@ -4,10 +4,6 @@ Title: "ToDo Actor" Usage: #definition * description = """ CapabilityStatement for Client Actor - -Explain -- blah -- blah """ * url = "https://profiles.ihe.net/RAD/IDR/CapabilityStatement/IHE.ToDo.client" * name = "IHE_ToDo_client" @@ -16,7 +12,7 @@ Explain * experimental = false * date = "2022-10-27" * kind = #requirements -* fhirVersion = #4.0.1 +* fhirVersion = #6.0.0-ballot3 * format[+] = #application/fhir+xml * format[+] = #application/fhir+json * rest @@ -97,10 +93,6 @@ Title: "ToDo Server Actor" Usage: #definition * description = """ CapabilityStatement for Server Actor. - -Explain -- blah -- blah """ * url = "https://profiles.ihe.net/RAD/IDR/CapabilityStatement/IHE.ToDo.server" * name = "IHE_ToDo_supplier" diff --git a/input/fsh/codesystem-idr-condition-category.fsh b/input/fsh/codesystem-idr-condition-category.fsh index 372defa..055aa73 100644 --- a/input/fsh/codesystem-idr-condition-category.fsh +++ b/input/fsh/codesystem-idr-condition-category.fsh @@ -3,9 +3,9 @@ Id: idr-impression-condition-category-cs Title: "IDR Impression category" Description: "Impression category codes for IDR" -* #imaging-impression "Imaging Impression" +* #diagnostic-imaging-impression "Imaging Impression" * ^experimental = false - +* ^caseSensitive = true ValueSet: IDRImpressionConditionCategoryVS Id: idr-impression-condition-category-vs diff --git a/input/fsh/example-Condition.fsh b/input/fsh/example-Condition.fsh new file mode 100644 index 0000000..0432bff --- /dev/null +++ b/input/fsh/example-Condition.fsh @@ -0,0 +1,72 @@ +Instance: example-Condition-Infarct +InstanceOf: IDRImpressionCondition +Title: "Condition: Pulmonary Infarct" +Description: "Pulmonary infarct in lower lobe of right lung" +Usage: #example + +* category = IDRImpressionConditionCategoryCS#diagnostic-imaging-impression +* clinicalStatus = FHIRConditionClinical#active +* verificationStatus = FHIRConditionVerStatus#provisional +* code = SCT#64662007 "Pulmonary infarct" + +* bodySite = SCT#10024003 "Base of lung" +/* TODO R6 adds bodyStructure which we prefer (and update to lower lobe of right lung) +* extension[bodyStructure] + * value[0] = +*/ +* subject = Reference(Patient/example-Patient) +* asserter = Reference(Practitioner/example-Practitioner-Radiologist) + +Instance: example-BodyStructure-Left-Breast +InstanceOf: BodyStructure +Title: "BodyStructure: Left Breast" +Usage: #example +* patient = Reference(Patient/example-Patient) +// R4 BodyStructure uses location + locationQualifier +* includedStructure[0].structure = http://snomed.info/sct#76752008 "Breast structure (body structure)" +* includedStructure[0].laterality = http://snomed.info/sct#7771000 "Left (qualifier value)" + +/* TODO Convert this to an observation? */ +Instance: example-Condition-Density +InstanceOf: IDRImpressionCondition +Title: "Condition: Suspicious Density" +Description: "A suspicious soft tissue density in the left breast" +Usage: #example + +* category = IDRImpressionConditionCategoryCS#diagnostic-imaging-impression +* clinicalStatus = FHIRConditionClinical#active +* verificationStatus = FHIRConditionVerStatus#provisional +* code = SCT#28328005 "Abnormal Radiologic Density" + +* bodyStructure = Reference(BodyStructure/example-BodyStructure-Left-Breast) +* subject = Reference(Patient/example-Patient) +* asserter = Reference(Practitioner/example-Practitioner-Radiologist) + + +Instance: example-Condition-ChestPain +InstanceOf: Condition +Title: "Condition: Chest Pain" +Description: "Chest Pain as current problem being worked up" +Usage: #example + +* category = FHIRConditionCategory#problem-list-item +* clinicalStatus = FHIRConditionClinical#active +* verificationStatus = FHIRConditionVerStatus#provisional +* code = ICD10#R07.9 "Chest pain, unspecified" + +* subject = Reference(Patient/example-Patient) +* asserter = Reference(Practitioner/example-Practitioner-Radiologist) + +Instance: example-Condition-ShortnessOfBreath +InstanceOf: Condition +Title: "Condition: Shortness of Breath" +Description: "Shortness of Breath as current problem being worked up" +Usage: #example + +* category = FHIRConditionCategory#problem-list-item +* clinicalStatus = FHIRConditionClinical#active +* verificationStatus = FHIRConditionVerStatus#provisional +* code = ICD10#R06.02 "Shortness of Breath" + +* subject = Reference(Patient/example-Patient) +* asserter = Reference(Practitioner/example-Practitioner-Radiologist) diff --git a/input/fsh/example-DiagnosticReport-chest-xray.fsh b/input/fsh/example-DiagnosticReport-chest-xray.fsh new file mode 100644 index 0000000..279000a --- /dev/null +++ b/input/fsh/example-DiagnosticReport-chest-xray.fsh @@ -0,0 +1,75 @@ +Instance: example-IDiagnosticReport-chest-xray +InstanceOf: ImagingDiagnosticReport +Title: "A DiagnosticReport: XR Chest" +Description: "Two View Chest XRay Report" +Usage: #example + +* subject = Reference(Patient/example-Patient) + +* category = SCT#309964003 "Radiology department" +* code = CPT#71045 "RADIOLOGIC EXAMINATION, CHEST; SINGLE VIEW" +* study = Reference(ImagingStudy/example-ImagingStudy) +// * procedure = Reference(Procedure/example-procedure-chest-xray) +* extension[comparison].valueReference = Reference(ImagingStudy/example-ImagingStudy-Comparison) + +* performer = Reference(Organization/example-Organization) +* resultsInterpreter = Reference(Practitioner/example-Practitioner-Radiologist) + +/* +* results[0] +*/ + +// Need to do R6toR4 to move conclusionCode from CodeableConcept to CodeableReference +* extension[conclusionCodeR][0].valueReference = Reference(Condition/example-Condition-Infarct) +* extension[conclusionCodeR][1].valueReference = Reference(Condition/example-Condition-Density) + +// Add Recommendation +* extension[recommendation].valueReference = Reference(ServiceRequest/example-ServiceRequest-Mammo-Recommendation) + +* status = #final +* issued = 2020-11-11T10:32:33-05:00 + +* text + * status = #additional + * div = """ +
+

Patient Name: Jane Doe

+

Date of Examination: 2020-11-11

+
+

Order:

+

Referring Physician: Welby, Marcus

+

Study: Chest X-Ray (PA and Lateral views)

+

Indications: Chest Pain, Shortness of Breath; Rule out pulmonary pathology

+
+
+

Procedure:

+

Standard posteroanterior (PA) and lateral views of the chest were obtained. The study is of diagnostic quality, with satisfactory inspiration and penetration.

+
+
+

Comparison:

+
    +
  • Chest X-Ray (Single view); 2020-01-05
    • +
+
+
+

Findings:

+

The cardiac silhouette is within normal size limits. Mediastinal contours are normal, with no evidence of widening or mediastinal shift.

+

The lung volumes are adequate and the vascular markings are within normal limits. A wedge-shaped opacity is noted in the right lower lobe, consistent with a pulmonary infarct. No obvious consolidation, significant pleural effusion, or other focal airspace disease is detected in the remaining lung fields.

+

The bony thorax, including the ribs, clavicles, and visible portions of the spine, shows no acute fracture or suspicious lytic/blastic lesions. Soft tissues of the chest wall are unremarkable, except for a small, suspicious density projected over the left breast region, which cannot be fully characterized on this examination.

+

The hemidiaphragms are smooth and sharply outlined. The costophrenic angles are clear. The visualized portions of the upper abdomen appear unremarkable.

+
+
+

Impression:

+
    +
  • Right lower lobe pulmonary infarct consistent with the clinical scenario.
    • +
  • Suspicious soft tissue density overlying the left breast region that warrants further evaluation.
    • +
+
+
+

Recommendation:

+
    +
  • Bilateral diagnostic mammogram; to followup suspicious soft tissue density
    • +
+
+
+ """ diff --git a/input/fsh/example-Endpoint.fsh b/input/fsh/example-Endpoint.fsh index b5ab6d8..f962c88 100644 --- a/input/fsh/example-Endpoint.fsh +++ b/input/fsh/example-Endpoint.fsh @@ -1,6 +1,6 @@ Instance: example-ImagingStudyEndpoint-Series InstanceOf: ImagingStudyEndpoint -Title: "Imaging Endpoint for Series example" +Title: "ImagingStudyEndpoint: Series" Description: "Simple Imaging Series Endpoint" Usage: #example * connectionType = FHIREndpoint#dicom-wado-rs "DICOM WADO-RS" @@ -11,8 +11,8 @@ Usage: #example Instance: example-ImagingStudyEndpoint-Study InstanceOf: ImagingStudyEndpoint -Title: "Imagin Endpoint for Study example" -Description: "Simple Imagin Study Endpoint" +Title: "ImagingStudyEndpoint: Study" +Description: "Simple Imaging Study Endpoint" Usage: #example * connectionType = FHIREndpoint#dicom-wado-rs "DICOM WADO-RS" * payload.type = DICOM#113014 "Study" @@ -22,8 +22,8 @@ Usage: #example Instance: example-ImagingStudyEndpoint-Study-Comparison InstanceOf: ImagingStudyEndpoint -Title: "Imaging Endpoint for Study example" -Description: "Simple Imaging Study Endpoint fpr the comparison study" +Title: "ImagingStudyEndpoint: Comparison Study" +Description: "Simple Imaging Study Endpoint for the comparison study" Usage: #example * connectionType = FHIREndpoint#dicom-wado-rs "DICOM WADO-RS" * payload.type = DICOM#113014 "Study" diff --git a/input/fsh/example-ImagingStudy.fsh b/input/fsh/example-ImagingStudy.fsh index bd70e96..845fd7a 100644 --- a/input/fsh/example-ImagingStudy.fsh +++ b/input/fsh/example-ImagingStudy.fsh @@ -1,6 +1,6 @@ Instance: example-ImagingStudy -InstanceOf: ImagingStudyInImagingReport -Title: "IMR ImagingStudy example" +InstanceOf: IDRImagingStudy +Title: "ImagingStudy: IMR example" Description: "Simple IMR ImagingStudy to be used in DiagnosticReport" Usage: #example * identifier[studyUID].system = DICOMUID @@ -8,16 +8,16 @@ Usage: #example * status = FHIRImagingStudyStatus#available * modality = DICOM#CR "Computed Radiography" * subject = Reference(Patient/example-Patient) -* started = 2020-12-31T23:30:50-05:00 +* started = 2020-11-11T10:20:50-05:00 * endpoint = Reference(Endpoint/example-ImagingStudyEndpoint-Study) -* procedure.concept.coding = CPT#71045 "RADIOLOGIC EXAMINATION, CHEST; SINGLE VIEW" +* procedure = Reference(Procedure/example-Procedure-chest-xray) * series.uid = "1.2.3.4.5.1" * series.modality = DICOM#CR "Computed Radiography" Instance: example-ImagingStudy-Comparison -InstanceOf: ImagingStudyInImagingReport -Title: "IMR ImagingStudy example" +InstanceOf: IDRImagingStudy +Title: "ImagingStudy: IMR Comparison example" Description: "Simple IMR ImagingStudy to be used as a comparison study in DiagnosticReport" Usage: #example * identifier[studyUID].system = DICOMUID @@ -25,8 +25,8 @@ Usage: #example * status = FHIRImagingStudyStatus#available * modality = DICOM#CR "Computed Radiography" * subject = Reference(Patient/example-Patient) -* started = 2020-01-01T23:30:50-05:00 +* started = 2020-01-05T23:30:50-05:00 * endpoint = Reference(Endpoint/example-ImagingStudyEndpoint-Study) -* procedure.concept.coding = CPT#71045 "RADIOLOGIC EXAMINATION, CHEST; SINGLE VIEW" +* procedure = Reference(Procedure/example-Procedure-chest-xray-comparison) * series.uid = "5.6.7.8.9.1" * series.modality = DICOM#CR "Computed Radiography" \ No newline at end of file diff --git a/input/fsh/example-Organization-and-Practitioner.fsh b/input/fsh/example-Organization-and-Practitioner.fsh index 9d655d4..22316b3 100644 --- a/input/fsh/example-Organization-and-Practitioner.fsh +++ b/input/fsh/example-Organization-and-Practitioner.fsh @@ -1,15 +1,24 @@ Instance: example-Organization InstanceOf: Organization -Title: "Organization example" +Title: "Organization: Imaging practice" Description: "Simple Organization to be used in DiagnosticReport" Usage: #example -* name = "YourHospital" +* name = "Mercy Hospital" -Instance: example-Practitioner +Instance: example-Practitioner-Radiologist InstanceOf: Practitioner -Title: "Practitioner example" +Title: "Practitioner: Radiologist" Description: "Simple Practitioner to be used in DiagnosticReport" Usage: #example -* name.family = "Guy" -* name.given = "Funny" \ No newline at end of file +* name.family = "Roentgen" +* name.given = "Roger" + + +Instance: example-Practitioner-Referring +InstanceOf: Practitioner +Title: "Practitioner: Referring" +Description: "Simple Practitioner to be used in DiagnosticReport" +Usage: #example +* name.family = "Welby" +* name.given = "Marcus" diff --git a/input/fsh/example-Patient.fsh b/input/fsh/example-Patient.fsh index b000594..ffd93b9 100644 --- a/input/fsh/example-Patient.fsh +++ b/input/fsh/example-Patient.fsh @@ -1,10 +1,11 @@ Instance: example-Patient InstanceOf: Patient -Title: "Patient example" +Title: "Patient: Jane Doe" Description: "Simple Patient" Usage: #example * identifier.type.coding = HL7V2#MR "Medical Record Number" * identifier.system = "http://www.acme.com/identifiers/patient" * identifier.value = "1234567" -* name.family = "Smith" -* name.given = "John" \ No newline at end of file +* name.family = "Doe" +* name.given = "Jane" +* gender = #female \ No newline at end of file diff --git a/input/fsh/example-Procedure.fsh b/input/fsh/example-Procedure.fsh index 82a5186..cd63ecc 100644 --- a/input/fsh/example-Procedure.fsh +++ b/input/fsh/example-Procedure.fsh @@ -1,9 +1,21 @@ -Instance: example-procedure-single-view-chest-xray +Instance: example-Procedure-chest-xray InstanceOf: Procedure -Title: "Simple XR Chest Procedure" -Description: "Radiologic Examination, Chest; Single View" +Title: "Procedure: XR Chest" +Description: "Radiologic Examination, Chest; Two View" +Usage: #example + +* status = #completed +* code = LOINC#36643-5 "XR Chest 2 Views" +* subject = Reference(Patient/example-Patient) +* basedOn = Reference(ServiceRequest/example-ServiceRequest-chest-xray) + +Instance: example-Procedure-chest-xray-comparison +InstanceOf: Procedure +Title: "Procedure: XR Chest (Comparison)" +Description: "Radiologic Examination, Chest; Single View; Comparison" Usage: #example * status = #completed * code = LOINC#36554-4 "XR Chest Single View" * subject = Reference(Patient/example-Patient) +* basedOn = Reference(ServiceRequest/example-ServiceRequest-chest-xray-comparison) diff --git a/input/fsh/example-ServiceRequest-single-view-chest-xray.fsh b/input/fsh/example-ServiceRequest-single-view-chest-xray.fsh index e47a3d9..ce34904 100644 --- a/input/fsh/example-ServiceRequest-single-view-chest-xray.fsh +++ b/input/fsh/example-ServiceRequest-single-view-chest-xray.fsh @@ -1,7 +1,7 @@ -Instance: example-ServiceRequest-single-view-chest-xray -InstanceOf: ImagingServiceRequest -Title: "Simple XR Chest" -Description: "Single View Chest XRay" +Instance: example-ServiceRequest-chest-xray +InstanceOf: IDRImagingServiceRequest +Title: "ServiceRequest: XR Chest" +Description: "Single View Chest XRay order" Usage: #example * identifier[accession].type = HL7V2#ACSN @@ -9,19 +9,19 @@ Usage: #example * identifier[accession].value = "A1234567" * status = #active - * intent = FHIRIntent#order "Order" - +* requester = Reference(Practitioner/example-Practitioner-Referring) * subject = Reference(Patient/example-Patient) - -* code.concept = CPT#71045 "RADIOLOGIC EXAMINATION, CHEST; SINGLE VIEW" +* code.concept = CPT#71046 "Radiologic examination, chest; 2 views" +* reason[0] = Reference(Condition/example-Condition-ChestPain) +* reason[1] = Reference(Condition/example-Condition-ShortnessOfBreath) +* reason[2].concept.text = "Rule out pulmonary pathology" - -Instance: example-ServiceRequest-single-view-chest-xray-history -InstanceOf: ImagingServiceRequest -Title: "Simple XR Chest History" -Description: "Single View Chest XRay of a Previous Completed Order" +Instance: example-ServiceRequest-chest-xray-comparison +InstanceOf: IDRImagingServiceRequest +Title: "ServiceRequest: XR Chest (Comparison)" +Description: "Single View Chest XRay of a previous completed order" Usage: #example * identifier[accession].type = HL7V2#ACSN @@ -29,18 +29,14 @@ Usage: #example * identifier[accession].value = "A111111" * status = #completed - * intent = FHIRIntent#order "Order" - * subject = Reference(Patient/example-Patient) - * code.concept = CPT#71045 "RADIOLOGIC EXAMINATION, CHEST; SINGLE VIEW" - Instance: example-ServiceRequest-CT-Abdomen-Pelvis -InstanceOf: ImagingServiceRequest -Title: "CT Abdomen Pelvis" +InstanceOf: IDRImagingServiceRequest +Title: "ServiceRequest: CT Abdomen Pelvis" Description: "CT Abdomen Pelvis order" Usage: #example @@ -49,9 +45,19 @@ Usage: #example * identifier[accession].value = "A222222" * status = #active - * intent = FHIRIntent#order "Order" - * subject = Reference(Patient/example-Patient) +* code.concept = CPT#74176 "COMPUTED TOMOGRAPHY, ABDOMEN AND PELVIS; WITHOUT CONTRAST MATERIAL" + -* code.concept = CPT#74176 "COMPUTED TOMOGRAPHY, ABDOMEN AND PELVIS; WITHOUT CONTRAST MATERIAL" \ No newline at end of file +Instance: example-ServiceRequest-Mammo-Recommendation +InstanceOf: IDRRecommendationServiceRequest +Title: "ServiceRequest: Mammography Recommendation" +Description: "Mammography Recommendation" +Usage: #example + +* status = #draft +* intent = #proposal +* subject = Reference(Patient/example-Patient) +* reason = Reference(Condition/example-Condition-Infarct) +* code.concept = CPT#77066 "Diagnostic mammography, including computer-aided detection (CAD) when performed; bilateral" diff --git a/input/fsh/valueset-diagnosticreport-status.fsh b/input/fsh/valueset-diagnosticreport-status.fsh index 34f047b..edbd87f 100644 --- a/input/fsh/valueset-diagnosticreport-status.fsh +++ b/input/fsh/valueset-diagnosticreport-status.fsh @@ -4,6 +4,6 @@ Title: "IDR DiagnosticReport.status ValueSet" Description: "Valueset for imaging diagnostic reports" * include FHIRDiagnosticReportStatus#preliminary -* include FHIRDiagnosticReportStatus#findal +* include FHIRDiagnosticReportStatus#final * include FHIRDiagnosticReportStatus#amended * ^experimental = false \ No newline at end of file diff --git a/input/ignoreWarnings.txt b/input/ignoreWarnings.txt index f3f9bc6..239bf10 100644 --- a/input/ignoreWarnings.txt +++ b/input/ignoreWarnings.txt @@ -3,4 +3,6 @@ # IHE valueset that is not yet a real valueset Code System URI 'urn:ihe:event-type-code' is unknown so the code cannot be validated - +This IG is version 6.0.0-ballot4, while the IG 'hl7.terminology.r5' is from version 5.0.0 +This IG is version 6.0.0-ballot4, while the IG 'hl7.fhir.uv.extensions.r5' is from version 5.0.0 +This IG is version 6.0.0-ballot4, while the IG 'hl7.fhir.uv.tools.r5' is from version 5.0.0 \ No newline at end of file diff --git a/input/images-source/ActorsAndTransactions.plantuml b/input/images-source/ActorsAndTransactions.plantuml index 480cc6b..e8374be 100644 --- a/input/images-source/ActorsAndTransactions.plantuml +++ b/input/images-source/ActorsAndTransactions.plantuml @@ -1,6 +1,14 @@ @startuml -skinparam svgDimensionStyle false -agent "[[#client Client]]" as Client -agent "[[#server Server]]" as Server -Client -down-> Server : "go [[domain-YY.html Domain-YY]]" -@enduml +' skinparam svgDimensionStyle false +skinparam linetype ortho + +agent "[[#56111-report-creator Report Creator]]" as Creator +agent "[[#56112-report-repository Report Repository]]" as Repository +agent "[[#56113-report-reader Report Reader]]" as Reader +agent "[[#56114-report-consumer Report Consumer]]" as Consumer + +Creator -down-> Repository : "Store Imaging Diagnostic Report [RAD-Y1]" +Reader ----left----> Repository : "Query Imaging Diagnostic Report [RAD-Y2]\n Retrieve Imaging Diagnostic Report [RAD-Y3]" +Consumer -[hidden]up-> Reader +Consumer ----[norank]----> Repository +@enduml \ No newline at end of file diff --git a/input/images-source/usecase1-processflow.plantuml b/input/images-source/usecase1-processflow.plantuml index 28118ec..7c6f696 100644 --- a/input/images-source/usecase1-processflow.plantuml +++ b/input/images-source/usecase1-processflow.plantuml @@ -1,12 +1,24 @@ @startuml skinparam svgDimensionStyle false hide footbox -participant "Client" as Client -participant "Server" as Server -activate "Client" -"Client" -> "Server" : 1. Go Query [domain-YY] -activate "Server" -"Server" --> "Client" : 2. Go Response [domain-YY] -deactivate "Client" -deactivate "Server" -@enduml + +title Report Creation + +participant "IM/IA" as IM +participant "Report\nCreator" as RC +participant "Clinical\nApplications" as CA +participant "Integrated\nReporting Apps" as IRA + +RC->RC ++: Initiate interpretation +loop Report Authoring Process +RC->IM ++: Retrieve Images (and related objects) +IM->RC --: +RC->RC --: Interact with\nImaging Clinician +RC->CA --++: Request\nClinical Analysis +CA->RC --: +RC->IRA ++: Access Reporting Functions +IRA->RC --: +end +RC->RC: Encode Report + +@enduml \ No newline at end of file diff --git a/input/images-source/usecase2-processflow.plantuml b/input/images-source/usecase2-processflow.plantuml new file mode 100644 index 0000000..a35b42d --- /dev/null +++ b/input/images-source/usecase2-processflow.plantuml @@ -0,0 +1,20 @@ +@startuml +skinparam svgDimensionStyle false +hide footbox + +title Report Storage & Distribution + +participant "Report\nCreator" as RC +participant "Report\nRepository" as RR +participant "Report\nConsumer" as RCS + +note over RC: Report Creation\n(Use Case #1) + +RC->RC ++: Sign Report +RC->RR --: Store Imaging Diagnostic Report [RAD-Y1] +RCS->RR ++: Query Imaging Diagnostic Report [RAD-Y2] +RR->RCS --: +RCS->RR ++: Retrieve Imaging Diagnostic Report [RAD-Y3] +RR->RCS --: + +@enduml \ No newline at end of file diff --git a/input/images-source/usecase3-processflow.plantuml b/input/images-source/usecase3-processflow.plantuml new file mode 100644 index 0000000..871a6fe --- /dev/null +++ b/input/images-source/usecase3-processflow.plantuml @@ -0,0 +1,14 @@ +@startuml +skinparam svgDimensionStyle false +hide footbox + +title Report Presentation + +participant "Report\nReader" as RC + +note over RC: Report Distribution\n(Use Case #2) + +RC->RC ++: Present Report +RC->RC: User Interaction with Report + +@enduml \ No newline at end of file diff --git a/input/images-source/usecase4-processflow.plantuml b/input/images-source/usecase4-processflow.plantuml new file mode 100644 index 0000000..a7c8274 --- /dev/null +++ b/input/images-source/usecase4-processflow.plantuml @@ -0,0 +1,14 @@ +@startuml +skinparam svgDimensionStyle false +hide footbox + +title Report Processing + +participant "Report\nConsumer" as RC + +note over RC: Report Distribution\n(Use Case #2) + +RC->RC ++: Extract Data from Report +RC->RC: Process + +@enduml \ No newline at end of file diff --git a/input/images/image1.jpeg b/input/images/image1.jpeg new file mode 100644 index 0000000..4459cc0 Binary files /dev/null and b/input/images/image1.jpeg differ diff --git a/input/pagecontent/index.md b/input/pagecontent/index.md index 280a325..384e56f 100644 --- a/input/pagecontent/index.md +++ b/input/pagecontent/index.md @@ -1,48 +1,68 @@ -
-**NOTE TO REVIEWERS**: This Imaging Diagnostic Report (IDR) Implementation Guide is work-in-progress. The PDF published at [IHE](https://profiles.ihe.net/RAD) 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. +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. +
+**IMPORTANT**: IDR is NOT yet recommended for production use. -| [Significant Changes, Open and Closed Issues](issues.html) | -{: .grid} +Profiles released for Trial Implementation by IHE Radiology typically ARE expected to be stable enough for production use; however, this release of IDR is intended for experimental implementation and feedback. +See [Significant Changes, Open and Closed Issues](issues.html)
### Organization of This Guide -The top level resource is the [Imaging Diagnostic Report](StructureDefinition-imaging-diagnosticreport.html). It references the following resource: - -- [Patient](StructureDefinition-idr-patient.html) -- [Order](StructureDefinition-imaging-service-request.html) -- Patient History - - [Condition](StructureDefinition-idr-patient-history-condition.html) - - [Observation](StructureDefinition-idr-patient-history-observation.html) - - [Procedure](StructureDefinition-idr-patient-history-procedure.html) - - [FamilyMemberHistory](StructureDefinition-idr-patient-history-family-member-history.html) -- [Procedure](StructureDefinition-idr-procedure.html) -- [Imaging Study](StructureDefinition-idr-imaging-study-in-imaging-report.html) -- [Comparison](StructureDefinition-idr-comparison-study.html) -- [Findings](StructureDefinition-idr-observation.html) -- Impression - - [Condition](StructureDefinition-idr-impression-condition.html) - - [Observation](StructureDefinition-idr-observation.html) -- [Recommendation](StructureDefinition-idr-recommendation-service-request.html) -- [Communication](StructureDefinition-idr-communication.html) -- [Signature](StructureDefinition-idr-signature-provenance.html) - - - - + 2. [Download and Analysis](download.html) + 3. [Test Plan](testplan.html) See also the [Table of Contents](toc.html) and the index of [Artifacts](artifacts.html) defined as part of this implementation guide. @@ -52,8 +72,9 @@ IHE uses the normative words: Shall, Should, and May according to [standards con #### Must Support -The use of ```mustSupport``` in StructureDefinition profiles equivalent to the IHE use of **R2** as defined in [Appendix Z](https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html#z.10-profiling-conventions-for-constraints-on-fhir). +The use of ```mustSupport``` in StructureDefinition profiles is equivalent to the IHE use of **R2** as defined in [Appendix Z](https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html#z.10-profiling-conventions-for-constraints-on-fhir). + +- The source actor shall populate the element 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. -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. +> Note: mustSupport of true only has meaning on elements with minimal cardinality of zero (0) but sometimes will appear on elements with a minimal cardinality greater than zero (0) due to inheritance from a less constrained profile. diff --git a/input/pagecontent/issues.md b/input/pagecontent/issues.md index b9f804d..e125b47 100644 --- a/input/pagecontent/issues.md +++ b/input/pagecontent/issues.md @@ -7,6 +7,16 @@ - change 2 - etc. +## Caveats + +- IDR uses the FHIR DiagnosticReport resource to model imaging reports typical of most radiology specialties. Planned further modeling of the report findings (Observation resources under DiagnosticReport.results) may expose issues which also result in backward incompatible changes. + +### Deferred to Future Work + +- Full coverage of the complexity of the Findings section is deferred to future work (See discussion in Section 6.Z.3.6). + +There are no examples of a full diagnostic report using this profile yet. + ## Issues ### Submit an Issue diff --git a/input/pagecontent/rad-Y1.md b/input/pagecontent/rad-Y1.md new file mode 100644 index 0000000..964ae49 --- /dev/null +++ b/input/pagecontent/rad-Y1.md @@ -0,0 +1,47 @@ +## 2:4.Y1 Store Imaging Diagnostic Report + +
+**NOTE TO READERS**: Transactions RAD-Y1, RAD-Y2 and RAD-Y3 are placeholders. + +Both this profile (IDR) and IHE Interactive Multimedia Reports (IMR) have transactions to store and query/retrieve reports based on FHIR DiagnosticReport. + +The intention is for IDR to become the base profile for reports. The IMR profile would be restructured to add its hyperlink details and behaviors either as a profile with IDR as a pre-requisite, or as named Options in IDR. + +In Phase II of IDR, IDR will "adopt" the IMR transactions, generalize the names, add any general requirements (e.g. more query details), and factor out any multimedia content back into IMR. +
+ +### 2:4.Y1.1 Scope + +This transaction is used to transfer an imaging diagnostic report in the form of a bundle of FHIR resources. The structure of the bundle and other constraints are specified in the Content Definition LATER. + +Considerations include: + +- For a "local" store, should the receiver be assumed to have access to pre-existing resources referenced in the report (e.g. the Patient that is the .subject) so those are not included in the bundle. (The newly created subresources of the report, like Observations, would be included in the bundle.) +- Should a different transaction (perhaps Export Imaging Diagnostic Report) be created that would not make that assumption and thus would include copies of all significant referenced resources in the bundle. +- In IMR RAD-141 Store Multimedia Report (https://profiles.ihe.net/RAD/IMR/RAD-141.html), the Bundle.type=transaction; it requires DiagnosticReport, optionally 0 or more ServiceRequest, ImagingStudy, ImagingSelection. NEED to extend with IDR reqs/opts + +### 2:4.Y1.2 Actors Roles + +**Table 2:4.Y1.2-1: Actor Roles** + +| Role | Description | Actor(s) | +|------|-------------|----------| +| Sender | Sends imaging reports | Report Creator | +| Receiver | Receives and handles imaging reports | Report Repository | +{: .grid} + +### 2:4.Y1.3 Referenced Standards + +### 2:4.Y1.4 Messages + +**Figure 2:4.Y1.4-1: Interaction Diagram** + +### 2:4.Y1.5 Security Considerations + +The patient and clinical details provided in the imaging diagnostic report constitute personal health information. + +#### 2:4.Y1.5.1 Security Audit Considerations + +Senders and Receivers that support the ATNA Profile shall audit this transaction. + +This transaction corresponds to a TODO ATNA Trigger Event. diff --git a/input/pagecontent/rad-Y2.md b/input/pagecontent/rad-Y2.md new file mode 100644 index 0000000..689ffae --- /dev/null +++ b/input/pagecontent/rad-Y2.md @@ -0,0 +1,48 @@ +## 2:4.Y2 Query Imaging Diagnostic Report + +
+**NOTE TO READERS**: Transactions RAD-Y1, RAD-Y2 and RAD-Y3 are placeholders. + +Both this profile (IDR) and IHE Interactive Multimedia Reports (IMR) have transactions to store and query/retrieve reports based on FHIR DiagnosticReport. + +The intention is for IDR to become the base profile for reports. The IMR profile would be restructured to add its hyperlink details and behaviors either as a profile with IDR as a pre-requisite, or as named Options in IDR. + +In Phase II of IDR, IDR will "adopt" the IMR transactions, generalize the names, add any general requirements (e.g. more query details), and factor out any multimedia content back into IMR. +
+ +### 2:4.Y2.1 Scope + +This transaction is used to query for imaging diagnostic report instances. + +The structure of the bundle and other constraints are specified in the Content Definition LATER. + +Considerations include: + +- Pull example query scenarios and patterns from the IDR Public Comment draft +- See the Find Multimedia Report [RAD-143] transaction: https://profiles.ihe.net/RAD/IMR/RAD-143.html + +### 2:4.Y2.2 Actors Roles + +**Table 2:4.Y2.2-1: Actor Roles** + +| Role | Description | Actor(s) | +|------|-------------|----------| +| Requester | Request imaging reports that match a filter | Report Reader
Report Consumer | +| Responder | Returns matching imaging reports | Report Repository | +{: .grid} + +### 2:4.Y2.3 Referenced Standards + +### 2:4.Y2.4 Messages + +**Figure 2:4.Y2.4-1: Interaction Diagram** + +### 2:4.Y2.5 Security Considerations + +The patient and clinical details provided in the imaging diagnostic report constitute personal health information. + +#### 2:4.Y2.5.1 Security Audit Considerations + +Requesters and Responders that support the ATNA Profile shall audit this transaction. + +This transaction corresponds to a TODO ATNA Trigger Event. diff --git a/input/pagecontent/rad-Y3.md b/input/pagecontent/rad-Y3.md new file mode 100644 index 0000000..90a0893 --- /dev/null +++ b/input/pagecontent/rad-Y3.md @@ -0,0 +1,49 @@ + +## 2:4.Y3 Retrieve Imaging Diagnostic Report + +
+**NOTE TO READERS**: Transactions RAD-Y1, RAD-Y2 and RAD-Y3 are placeholders. + +Both this profile (IDR) and IHE Interactive Multimedia Reports (IMR) have transactions to store and query/retrieve reports based on FHIR DiagnosticReport. + +The intention is for IDR to become the base profile for reports. The IMR profile would be restructured to add its hyperlink details and behaviors either as a profile with IDR as a pre-requisite, or as named Options in IDR. + +In Phase II of IDR, IDR will "adopt" the IMR transactions, generalize the names, add any general requirements (e.g. more query details), and factor out any multimedia content back into IMR. +
+ +### 2:4.Y3.1 Scope + +This transaction is used to retrieve imaging diagnostic report instances. + +The structure of the bundle and other constraints are specified in the Content Definition LATER. + +Considerations include: + +- Pull example query scenarios and patterns from the IDR Public Comment draft +- See the Find Multimedia Report [RAD-143] transaction: https://profiles.ihe.net/RAD/IMR/RAD-143.html + +### 2:4.Y3.2 Actors Roles + +**Table 2:4.Y3.2-1: Actor Roles** + +| Role | Description | Actor(s) | +|------|-------------|----------| +| Requester | Request an imaging report | Report Reader
Report Consumer | +| Responder | Return the imaging report | Report Repository | +{: .grid} + +### 2:4.Y3.3 Referenced Standards + +### 2:4.Y3.4 Messages + +**Figure 2:4.Y3.4-1: Interaction Diagram** + +### 2:4.Y3.5 Security Considerations + +The patient and clinical details provided in the imaging diagnostic report constitute personal health information. + +#### 2:4.Y3.5.1 Security Audit Considerations + +Requesters and Responders that support the ATNA Profile shall audit this transaction. + +This transaction corresponds to a TODO ATNA Trigger Event. diff --git a/input/pagecontent/volume-1.md b/input/pagecontent/volume-1.md new file mode 100644 index 0000000..459226f --- /dev/null +++ b/input/pagecontent/volume-1.md @@ -0,0 +1,1538 @@ + +# 56 Imaging Diagnostic Report (IDR) + +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 + +## 56.1 IDR Actors, Transactions, and Content Modules + +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](https://profiles.ihe.net/GeneralIntro/ch-A.html). +IHE Transactions can be found in the Technical Frameworks General Introduction [Appendix B](https://profiles.ihe.net/GeneralIntro/ch-B.html). +Both appendices are located at . + +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](#563-idr-required-actor-groupings)). + +
+{%include ActorsAndTransactions.svg%} +
Figure 56.1-1: IDR Actor Diagram
+ +
+ +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** + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ActorsTransactionsInitiator or ResponderOptionalityReference
Report CreatorStore Imaging Diagnostic Report [RAD-Y1]InitiatorRRAD TF-2: 4.Y1
Report RepositoryStore Imaging Diagnostic Report [RAD-Y1]ResponderRRAD TF-2: 4.Y1
Query Imaging Diagnostic Report [RAD-Y2]ResponderRRAD TF-2: 4.Y2
Retrieve Imaging Diagnostic Report [RAD-Y3]ResponderRRAD TF-2: 4.Y3
Report ReaderQuery Imaging Diagnostic Report [RAD-Y2]InitiatorRRAD TF-2: 4.Y2
Retrieve Imaging Diagnostic Report [RAD-Y3]InitiatorRRAD TF-2: 4.Y3
Report ConsumerQuery Imaging Diagnostic Report [RAD-Y2]InitiatorRRAD TF-2: 4.Y2
Retrieve Imaging Diagnostic Report [RAD-Y3]InitiatorRRAD TF-2: 4.Y3
+ +### 56.1.1 Actor Descriptions and Actor Profile Requirements + +Most requirements are documented in RAD TF-2: Transactions. This section +documents any additional requirements on profile’s actors. + +#### 56.1.1.1 Report Creator + +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. + +#### 56.1.1.2 Report Repository + +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. + +#### 56.1.1.3 Report Reader + +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. + +#### 56.1.1.4 Report Consumer + +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. + +## 56.2 IDR Actor Options + +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** + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ActorOption NameReference
Report CreatorNo options defined--
Report RepositoryNo options defined--
Report ReaderNo options defined--
Report ConsumerNo options defined--
+ +## 56.3 IDR Required Actor Groupings + +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 ActorActor(s) to be grouped withReferenceContent Bindings Reference
Report CreatorITI CT / Time ClientITI TF-1: 7.1--
Report RepositoryNone----
Report ReaderNone----
Report ConsumerNone----
+ +## 56.4 IDR Overview + +### 56.4.1 Concepts + +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". + +#### 56.4.1.1 Report Formats: ORU, PDF, SR, CDA, FHIR + +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](https://build.fhir.org/ig/HL7/dicom-sr/)). 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 +(): + +- 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. + +#### 56.4.1.2 Purpose and Structure + +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. + +##### 56.4.1.2.1 Sections + +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](https://www.acr.org/-/media/ACR/Files/Practice-Parameters/communicationdiag.pdf?la=en) +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](https://www.rcr.ac.uk/system/files/publication/field_publication_files/bfcr181_standards_for_interpretation_reporting_0.pdf). + +- 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%. + +#### 56.4.1.3 Codes and Codesets + +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). + +#### 56.4.1.4 Relevant FHIR Resources + +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](https://hl7.org/fhir/diagnostics-module.html#org-dr-obs). + +The [**Patient**](https://www.hl7.org/fhir/R5/patient.html) 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**](https://www.hl7.org/fhir/R5/servicerequest.html) +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**](https://www.hl7.org/fhir/R5/encounter.html) 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**](https://www.hl7.org/fhir/R5/procedure.html) 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**](https://www.hl7.org/fhir/R5/imagingstudy.html) +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**](https://www.hl7.org/fhir/R5/diagnosticreport.html) +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](https://profiles.ihe.net/RAD/IMR/). + +The [**ImagingSelection**](https://www.hl7.org/fhir/R5/imagingselection.html) +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**](https://www.hl7.org/fhir/R5/observation.html) +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**](https://www.hl7.org/fhir/r5/condition.html) 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**](https://www.hl7.org/fhir/R5/bundle.html) 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**](https://www.hl7.org/fhir/R5/composition.html) +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**](https://www.hl7.org/fhir/R5/documentreference.html) +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. + +#### 56.4.1.5 Preliminary Reports, Final Reports, and Addendums + +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. + +#### 56.4.1.6 Narrative vs Encoded Content and Structure + +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" + + - E.g., AI analysis data underlying the summary conclusion that was + included + +- 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. + +#### 56.4.1.7 Environmental Assumptions + +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 +() + +Future revisions of this document might provide guidance specific to +imaging diagnostic reports and related resources. + +### 56.4.2 Use Cases + +#### 56.4.2.1 Use Case \#1: Report Creation + +A Report Creator encodes the report content. + +##### 56.4.2.1.1 Report Creation Use Case Description + +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. + +##### 56.4.2.1.2 Report Creation Process Flow + +
+{%include usecase1-processflow.svg%} +
Figure 56.4.2.1.2-1: Report Creation Process Flow
+
+ +#### 56.4.2.2 Use Case \#2: Report Storage & Distribution + +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). + +##### 56.4.2.2.1 Report Storage & Distribution Use Case Description + +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 + + - Constrain to a given time range, and/or body part, and/or + modality, and/or procedure + +- 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. + + - "Recent" involves searching for reports in a time range up to the + present. The size of the range is likely a local configuration or + user choice. + +- 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 + + - For a given ImagingStudy, find reports that reference it as .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 + + - Some may specifically target those with resections from the past + week (and see if the pathology results match), others focus on + multi-disciplinary 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". + + - Note that the workflow (especially for residents) may involve + multiple authors and the relevant author to search for may shift + over time, or depend on who is doing the query + +- Prior-based – find reports that cite a certain prior (perhaps there + was a quality issue) + + - For a given ImagingStudy, find reports that reference it as + .comparison + +- 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 + + - A similar query might be used by a reading clinician to find reports + with similar diagnoses to the current study to review/compare those + findings and images. + +- Observation-based – find observations that were created as findings, + without necessarily considering the entire report. + + - For a given Patient and DiagnosticReport, find Observations with + particular observation codes and/or bodyPart or bodyStructures, etc. + + + + - 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. + + - Caveat: it is not yet clear whether it would be simpler to retrieve + the current (and perhaps recent) reports and operate on that + collection of observations rather than do queries on the entire FHIR + store. + +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. + +##### 56.4.2.2.2 Report Storage & Distribution Process Flow + +
+{%include usecase2-processflow.svg%} +
Figure 56.4.2.2.2-1: Report Storage & Distribution Process Flow
+
+ +#### 56.4.2.3 Use Case \#3: Report Presentation + +A Report Reader presents the content of the diagnostic report to users +performing clinical tasks. + +##### 56.4.2.3.1 Report Presentation Use Case Description + +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 + + - Finding the answer to their clinical question in the recent order + for their patient (this might involve initially presenting the + impression and recommendations) + +- Surgeon + + - Understanding the patient's condition and disease to plan a surgical + procedure (this might involve focusing on details related to + specific anatomy and presentation of key images or 3D renderings) + +- Oncologist + + - Understanding the patient's condition and disease as part of + planning treatment (this might involve compiling details from the + current report and prior reports for presentation in tabular or + graphical form to better visualize progression or response.) + +- Emergency Physician + + - Understanding the patient's condition and disease as part of + stabilizing and admitting (this might involve focusing first on the + most urgent impression items and auto-staging orders based on report + recommendations or clinical decision support, e.g. anti-coagulation + medications for identified deep vein thrombosis, or a vascular + surgeon consult for an abdominal aortic aneurysm above a certain + size. See also smart infrastructure behaviors in Use Case \#4: + Report Processing.) + +- Radiologist + + - Understanding the main findings and impressions from a prior report + in the context of a current read. + +- 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) + + - Consider the scenario of a report being provided directly to the + patient, before review of the content with the referring + physician. Some diagnoses provoke emotional reactions and patients + benefit from corresponding education. Tools that "translate and + contextualize the content" could provide significant value. + Tooling that can mediate release of reports with certain findings + until after physician consultation, while immediately releasing + others, might be of interest in some practices. + + - 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.) + + - Reviewing a submitted case as part of the curation process + +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. + +##### 56.4.2.3.2 Report Presentation Process Flow + +
+{%include usecase3-processflow.svg%} +
Figure 56.4.2.3.2-1: Report Presentation Process Flow
+
+ +#### 56.4.2.4 Use Case \#4: Report Processing + +A Report Consumer extracts and processes relevant details from the +diagnostic report. + +##### 56.4.2.4.1 Report Processing Use Case Description + +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. + +###### 56.4.2.4.1.1 Ordering Support for Recommendations + +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. + +###### 56.4.2.4.1.2 Clinical Decision Support for the Referring Physician + +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. + +###### 56.4.2.4.1.3 Actionable Finding and Recommendation Follow-up + +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. + +###### 56.4.2.4.1.4 Clinical Registry Submissions + +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. + +###### 56.4.2.4.1.5 Smart Notifications & Routing of Reports + +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. + +###### 56.4.2.4.1.6 QA and Safety Processes + +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. + +###### 56.4.2.4.1.7 Other Workflow Automation + +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. + +##### 56.4.2.4.2 Report Processing Process Flow + +
+{%include usecase4-processflow.svg%} +
Figure 56.4.2.4.2-1: Report Processing Process Flow
+
+ +## 56.5 IDR Security Considerations + +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. + +## 56.6 IDR Cross Profile Considerations + +**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. diff --git a/input/pagecontent/volume-3.md b/input/pagecontent/volume-3.md new file mode 100644 index 0000000..f1d85a9 --- /dev/null +++ b/input/pagecontent/volume-3.md @@ -0,0 +1,1263 @@ +## 6.7 Imaging Diagnostic Report Content + +### 6.7.1 Scope + +This IHE Radiology Content Specification defines standard encodings for diagnostic reports on imaging procedures. It is specifically intended to cover the output of reporting systems following the interpretation performed by an imaging clinician such as a radiologist. + +Refer to [IHE RAD TF-1:56.4.1.2](volume-1.html#56412-purpose-and-structure) for real world expectations in the various report sections. + +Pathology and Interventional procedures are not specifically addressed. + +### 6.7.2 Referenced Standards + +- FHIR-R4: [HL7 FHIR Release 4.0](http://www.hl7.org/FHIR/R4) + +- FHIR-R5: [HL7 FHIR Release 5.0](http://www.hl7.org/FHIR/R5) + +- FHIR R6 + +- FHIR ImagingSelection: ImagingSelection + +- LATER – Reference other FHIR Resources + +#### 6.7.2.1 FHIR Versions and Extensions + +Implementations shall support the use of FHIR R4 resources. + +Implementations may also be configurable to support the use of FHIR R5 and/or FHIR R6 resources. + +This profile depends on a number of extensions introduced in FHIR R5 and FHIR R6 to address key details for coded imaging diagnostic reports. + +When encoding or parsing FHIR R4 resources, implementations shall support the additional elements specified in this Profile as extensions in the manner described here: + +Implementers may find one or more “FHIR extension packs” available to +facilitate the support of elements introduced in FHIR R5 (and/or +eventually FHIR R6). + +TODO Update the text to more specifically describe the IDR-R4-to-R5-and-R6 extensions mechanism, and any IDR extensions (which go beyond R4/5/6) + +### 6.7.3 Imaging Diagnostic Report Encodings + +This content definition makes normative profiling changes to the following FHIR Resources: + +- [DiagnosticReport](StructureDefinition-imaging-diagnosticreport.html) + +- [ServiceRequest](StructureDefinition-idr-imaging-service-request.html) (Order) +- [ServiceRequest](StructureDefinition-idr-recommendation-service-request.html) (Recommendation) + +- [Procedure](StructureDefinition-idr-imaging-procedure.html) (Imaging Procedure) + +- [ImagingStudy](StructureDefinition-idr-imaging-study.html) (Reported or Comparison Study) - DICOM Study UID & text + +- [Observation](StructureDefinition-idr-observation.html) (Findings) (Impression) +- [Observation](StructureDefinition-idr-patient-history-observation.html) (History) + +- [Condition](StructureDefinition-idr-patient-history-condition.html) (History) +- [Condition](StructureDefinition-idr-impression-condition.html) (Impression) + +- [Communication](StructureDefinition-idr-communication.html) + +This content definition makes only usage clarifications to the following FHIR Resources: + +This content definition uses without change the following FHIR Resources: + +- [Patient](StructureDefinition-idr-patient.html) (Subject) except guidance on Patient.text? +- [FamilyMemberHistory](StructureDefinition-idr-patient-history-family-member-history.html) except .text +- [Procedure](StructureDefinition-idr-patient-history-procedure.html) (History) except .text +- [Encounter](https://www.hl7.org/fhir/R5/encounter.html) (Imaging Encounter) + +- Provenance + +- [Practitioner](https://www.hl7.org/fhir/R5/practitioner.html) + +The Report Creator is expected to populate much of the contextual metadata (e.g., patient demographics, patient identifiers and issuers, study accession number, etc.) in the imaging diagnostic report resources based on values in the medical imaging data being processed, and/or the reporting worklist entry. + +This content definition does not presume that all semantics in the report that are potentially codeable are actually coded in this resource. Profiles will likely identify some specific details which are required to be coded to conform to that profile; however, systems processing diagnostic reports should generally assume that there may be details in the narrative which are not also encoded. See also TOLINK RAD TF-1: 56.4.1.6 Narrative vs Encoded Content and Structure. + +> Note: This profile changes the cardinality from 0.. to 1.. for some FHIR resource attributes. This is done when absence of the attribute would break interoperability. It is not done to enforce the presence of information that is simply desirable or convenient. + +This section describes requirements that are also represented in a companion [IDR FHIR IG](https://build.fhir.org/ig/IHE/RAD.IDR/branches/public-comment/index.html) (Implementation Guide). Some of these requirements involve extensions to the FHIR Resources. + +TODO: Since there is the risk that reiterated/duplicated content could diverge, any remaining content here will likely be reframed as informative and moved to Concepts, to an Informative Annex, to an IG Resource page, or dropped if all the discussion can be conveniently captured in the IG. + +In IMR, there is no Vol 3 Content Definition; the IMR Transactions +reference directly to Profiled Resource pages in the IG. Finding a way +to splice FHIR IGs into Content Definitions might be another option. +Discuss with Lynn/ITI. + +This profile adds extension attributes (marked as "\") to several +existing resources. + +The following text describes how the necessary structure and content of +an imaging diagnostic report, as described in IHE RAD TF-1:56.4.1.2, +would be encoded in FHIR. + +#### 6.7.3.0 Diagnostic Report + +DiagnosticReport.text contains the fully rendered human-readable form of the diagnostic report as described in 6.7.3.11. TOLINK + +#### 6.7.3.1 Patient + +Narrative text in the patient section of the diagnostic report is a good +candidate for auto-generation based on a subset of the coded content in +the Patient resource, such as the sex and age of the patient. The name +and medical record number are typically rendered into the top of the +report as well. + +- The Patient resource has a Patient.text attribute which can contain a + one-line description of the Patient, although since the Patient + resource is widely shared, the summary text may or may not match the + needs of the imaging diagnostic report, so the Human-Readable Form in + DiagnosticReport.text may be freshly generated. + +#### 6.7.3.2 Order + +Narrative text in the order section of the diagnostic report is a good +candidate for auto-generation based on a subset of the coded content in +the ServiceRequest resource. The ordered exam in ServiceRequest.code is +usually rendered as a single line, perhaps based on the display value of +the CodeableConcept. The Accession \# and the ordering physician may +also be rendered into the top of the report. + +- Each referenced ServiceRequest resource has a ServiceRequest.text + attribute which can contain a one-line description of the order. + +> Note 1. The Indications and Clinical Questions, while captured at the time of the order and conveyed to the Report Creator in the referenced ServiceRequest, are typically rendered into the narrative in the History section of the report. +> +> Note 2. The details in the Procedure section are pulled from the imaging Procedure Resource (which is what was performed based on patient needs) rather than the imaging ServiceRequest (which is what was ordered and sometimes driven by billing requirements) since the two do not always exactly match. Sometimes there is an effort to update the order to match the actual procedure; ideally if that does happen, it is best to do it before image interpretation to avoid the possibility that the ServiceRequest resource bundled with the DiagnosticReport is out of date with respect to the master copy of the reference. Sometimes the original order is cancelled and replaced by a new one in which case the Order reference/link is broken (but it is clear that something has changed). Resolving such issues is a workflow topic that is out of scope for this profile. + +#### 6.7.3.3 History + +**History** shall reference resource items in \ +DiagnosticReport.patientHistory. + +Notes: 1. While the specification requires the ability to include coded +history information, it does not specify which or how much history +information is encoded. Reports do not include the entire medical +history available but rather include history details determined to be +relevant to the study, usually by the imaging clinician,. Also, the +details are coded as known to the imaging clinician at the time of +interpretation; different information may be available when any given +reader reads the report, but the report will reflect what was known at +interpretation. + +2\. Often this history will include key details that also serve as the +indication(s) for the imaging study. The information coded in the +ServiceRequest.reason (See 6.7.3.2 Order) the definitive record in the +indications, even if they are also duplicated here. + +- Condition shall be used to encode past diagnoses. + +- Observation shall be used to record relevant observations from + the referring physician, nursing notes, past care, and past + diagnostics such as anatomic histopathology or clinical laboratory + result values. + +- Procedure shall be used to record past procedures performed on + the patient such as knee surgery, an appendectomy, or spinal fusion. + +- FamilyMemberHistory shall be used to record a person's + relationship to the patient, along with the persons demographics, + known conditions and procedures. + +Narrative text in the history section of the diagnostic report is a good +candidate for auto-generation based on the coded content in the +referenced resources, however the process of selecting the relevant +subset will likely require input from the imaging clinician or a +sophisticated algorithm. + +- This narrative is where indications for the exam (if any) and clinical + questions from the referring are included. Information for those two + items will be accessed via the imaging ServiceRequest referenced in + the .basedOn attribute rather than this .history attribute. + +- Each referenced Condition, Observation, Procedure, and + FamilyMemberHistory has a .text attribute which can contain a brief + description which may be assembled into the narrative text for the + History section. + +- See also the discussion of .text usage in Section 6.7.3.11.1 + Resources.text. + +#### 6.7.3.4 Procedure + +**Procedure** and Materials information shall be encoded in Procedure +resource(s) referenced in a \ DiagnosticReport.procedure +attribute. + +Notes: The DiagnosticReport.procedure attribute mirrors the +.specimen attribute to describe how the data being reported was obtained +and prepared. + +Procedure resources describe a procedure that was performed. They +provide details about technique and execution using clinical imaging +language and codes and are created using information from the modality. +In contrast, the ServiceRequest resource describes the order using +orderable language and codes, which are typically more general and +billing-oriented, and is created using information from the order +placer. Further, the ImagingStudy resource describes and provides links +for the actual **Study** data produced by the procedure(s), and is +referenced from DiagnosticReport.study. + +In the large majority of cases, one report will correspond to one study +comprised of one procedure. Some studies do involve multiple procedures, +e.g. a cardiac stress-rest workup, so systems shall be prepared to +handle multiple procedures. + +Procedure likely needs more profiling for imaging workflow and +record-keeping, however that is out of scope for this Diagnostic Report +Profile, and would be better addressed in concert with profiling imaging +ServiceRequest. Until it is fully profiled, the current practice of +user-generated text in the Procedure section of the +DiagnosticReport.presentedForm will need to serve. + +Narrative text in the procedure section of the diagnostic report is a +good candidate for auto-generation, since it involves little to no +interpretation. The text may be available in Procedure.text, +which in turn would be based on a subset of the coded content in the +referenced resource(s), usually the modality, date, procedure type, and +details such as technique, pulse sequences, contrast usage, radiation +dose, and generated images/views. The content of the Procedure resource +likely originated from the image header, MPPS, RDSR, and performed +procedure protocols. + +- Recent FHIR IG work allows the Dose Reporter to provide the Report + Creator with a formatted, locally-conformant block of text that + assembles the correct subset of dose details for the specific + procedure type for insertion into the report (typically to comply with + local regulations). + +During the imaging procedure, Observations might be created to capture +things like nursing notes or technologist observations. Those would be +associated with the Encounter for the imaging Procedure. Conveying those +to the radiologist as inputs for interpretation is not addressed here +since this profile is about encoding the resulting report. Future work +on reporting workflow and managing inputs to the radiologist could +address this. + +#### 6.7.3.5 Comparison + +**Comparison** studies shall be encoded in ImagingStudy resources +referenced from a \ DiagnosticReport.comparison attribute. + +This serves as the "library" of studies the imaging clinician took into +consideration. Actual comparison observations, both new comparative +statements and cited old statements from the prior study, are encoded +below with the findings. + +Narrative text in the comparison section of the diagnostic report is a +good candidate for auto-generation based on enumerating the coded +content in the referenced resources, usually the modality, date, and +procedure type. + +- Each referenced ImagingStudy resource has an ImagingStudy.text + attribute which can contain a one-line description of the study. + +#### 6.7.3.6 Findings + +Implementations are permitted to create reports where none of the +findings in the narrative are encoded. **Findings** that are encoded +shall use Observation resources referenced from +DiagnosticReport.result. Implementations shall be capable of +creating at least one Finding encoded as an Observation and referencing +it from DiagnosticReport.result. + +The following metadata shall be populated in the Observation (despite +being referenced, or implicit, in the DiagnosticReport). One reason for +this is to facilitate usage of the Observation resources beyond the +direct context of the parent DiagnosticReport. For example, to perform +Observation-level queries. + +- Observation.subject shall reference the imaged Patient. + +- Observation.basedOn shall reference the imaging + ServiceRequest + +- Observation.encounter, if present, shall reference the imaging + procedure Encounter. + +- Observation.partOf shall reference the interpreted + ImagingStudy + +- Observation.category shall use the value "imaging" + +- Observation.status shall use "final" for observations in the + final report. + +The scope and complexity of report findings can vary significantly. + +NOTE TO IMPLEMENTERS: Further profiling of the Findings section is +deferred to future work. + +As a strategic scoping decision of this profile, the use cases focus on +subsequent usage of imaging reports by referring physicians and +patients, and clinical pathway automation such as recommendation +follow-up, critical finding tracking, and clinical decision support for +referring physicians. Those use cases depend primarily on the Impression +and Recommendation sections which are the primary interest for referring +clinicians. The imaging clinician has summarized all the most important +clinical information in the Impression section where all conclusions and +actionable findings should be represented. + +Addressing the enormous range and variety of imaging findings will be a +significant undertaking. One significant avenue for bringing structure +to the problem will be exploring the use of CDE Sets, which are defined +groups of common data elements (and values) for describing specific +imaging findings. + +Future work on Finding encoding will consider use cases centered on the +interpretation process that leads to the report. This may bring together +AI result review and transcoding, the IRA profile, selecting findings +from prior reports for inclusion in the current report, using LLM +technologies to compose and process blocks of text, and other automation +functions for the imaging clinician. Such use cases will be helpful +concrete drivers in resolving the many expected complexities. Such work +will likely manifest in the form of a Findings Option to this Profile to +avoid disrupting any existing implementations and data from this Trial +Implementation draft of the IDR Profile. + +Findings that the radiologist chose to include in the report, but which +originated from AI models, will likely include related details in the +metadata and/or provenance of that finding. Such details will be +accessible to recipients of the report. Conversely, details about the +reporting process, such as what AI models were or were not run, and what +findings were not included in the report, may be documented by +associated systems in relevant logs, but will not appear in directly in +the report itself unless the radiologist chooses to include such +details, for example by describing that in the Procedure/Technique +section. + +#### 6.7.3.7 Impression / Conclusion + +Implementations shall +be able to create at least one Condition and reference it in the +DiagnosticReport.conclusionCode. + +The following bullets focus on impression statements as structured coded +data. The Report Creator is responsible for distinguishing and encoding +dictated impressions, recommendations, and communications. + +- +- Condition.actionable \ shall, if present, contain a code + to indicate the degree to which the Impression finding is actionable. + Codes may be drawn from the RadLex codes for the ACR Actionable + Finding Categories described in IHE Results Distribution (RD): + + - (RID49480, RadLex, "Cat 1 Emergent Actionable Finding") defined as + requiring immediate medical attention within minutes. + + - (RID49481, RadLex, "Cat 2 Urgent Actionable Finding") defined as + requiring medical attention within hours. + + - (RID49482, RadLex, "Cat 3 Non-critical Actionable Finding") defined + as requiring medical attention within days to months. + + - (RID50261, RadLex, "Non-actionable") defined as not requiring + follow-up actions. + +> Note 1. The presence of a Recommendation for a given impression is an implicit indication that it is actionable. Having an explicit code can help with subsequent tracking and follow-up. +> +> Note 2. Conversely, actionable findings do not always have a corresponding Recommendation. For example, an identified pneumothorax is a well-known entity to the referring clinician with standard actions to address it. The imaging clinician would be unlikely to re-iterate those actions in the report. +> +> Note 3. Category 1 and Category 2 codes constitute "critical findings" which often result in direct Communications (see Section 6.7.3.9) due to the clinical urgency. + +The narrative form of the Impression section is often directly dictated +by the imaging clinician. Tools also exist that generate a draft of the +Impression narrative based on the dictated Findings narrative. If the +Impression narrative were built up from the coded Impression, the +summary in Condition.text of each referenced Condition resource might be +compiled into impression bullets sequenced according to the +Condition.order. + +In addition to rendering the Impression narrative as a section in the +full report in the DiagnosticReport.text attribute, the Report +Creator may also render the Impression narrative into +DiagnosticReport.conclusion as a single markdown field. The +Impression narrative may contain dictated text which goes beyond the +semantics captured in the DiagnosticReport.conclusionCode +references. + +If/when one of these Conditions is added to the patient Problem List, +either by the referring physician or because the +Condition.verificationStatus is confirmed, that would likely create a +new Condition resource that might point to the Impression Condition +instance as Condition.evidence (or maybe the biopsy result instead). +While the Problem List Condition instance would be updated over time, +for example when the condition is abated, the Impression Condition +persists as a medicolegal snapshot that is an integral component of the +Report. If the Report is exported, that bundle would contain the +Impression Condition at the time of the report, not any "current" +version. + +#### 6.7.3.8 Recommendations + +**Recommendations**, if any, shall be encoded as ServiceRequest, +CommunicationRequest, or CarePlan resources referenced from the +DiagnosticReport.recommendation attribute. + +Recommendations for subsequent imaging, lab tests, or specialist +consultations would be encoded as draft ServiceRequests. Recommendations +for simpler communications would be encoded as draft +CommunicationRequests. + +These draft ServiceRequests and CommunicationRequests, when created, may +omit various details that the imaging clinician would not know or would +not be responsible for choosing. They are intended to serve as a +skeleton that facilitates the referring provider adding any needed +details and activating it as an order. + +- serviceRequest.status shall use the value draft ("The request + has been created but is not yet complete or ready for action.") + + - This reflects the fact that it is ultimately up to the referring + physician whether or not to act on one or more recommendations in + the report. Also, the request will be sparsely encoded and things + like procedure codes might not be locally correct so completion of + details and code re-mapping might be needed before the request can + be activated. + +- serviceRequest.intent shall use the value proposal (to leave it + up to the referring physician) or plan (if the imaging clinician feels + it would be inappropriate if the recommended action does not take + place) + +- serviceRequest.reason may reference a Condition resource in the + Impression when the recommendation was motivated by that specific + impression. This serves both to justify the recommendation, and to + associate the recommendation with the impression which can influence + their presentation. + +Note: To capture specific clinical/practice guidelines or literature +citations that were applied in making the recommendation (e.g., the +Fleischner Criteria for lung nodule follow-up), those can also be +referenced from ServiceRequest.reason. In HL7 v2, the IHE Results +Distribution (RD) Profile encoded this in OBX-15. Since there is not +currently a PracticeGuideline resource, it would be necessary to create +a DocumentReference resource for the relevant policy or guideline +document. + +- ServiceRequest.occurrence supports encoding a Period, i.e., a + time range. Per FHIR, the context of use will make it clear that one + value from the period applies. To encode a recommendation that a + follow-up scan take place 6-9 months from now, the Report Creator + calculates a start date 6 months from the current date, and an end + date 9 months from the current date. + +- ServiceRequest.performerType can be used to encode a referral + to a particular type of specialist. + +- ServiceRequest.orderDetail can be used to further specify + protocol parameters, acquisition technique, desired views, patient + preparation, etc., as appropriate. Detailed guidance on this is beyond + the scope of this profile. + +There is idiosyncratic variation between specialties, regions, and +facilities as to whether recommendations are presented in the +impressions section or presented separately. Since the underlying +encoding of a recommendation differs from an impression, this profile +separates the two. Implementations may still choose to group the two +together in the presented form based on configuration and customer +preferences. + +A recommendation is often directly associated with a specific +impression. This may be expressed in the dictated text by following the +impression with a recommendation before moving on to the next +impression. The Report Creator is responsible for maintaining the order +and relationships between impressions and recommendations. + +The narrative form of the Recommendations may be directly dictated by +the imaging clinician. Tools also exist that generate a draft of the +Recommendation narrative based on the Impressions and associated +guidelines. If the Recommendation narrative is built up from the coded +Recommendation, the summary in ServiceRequest.text of each +referenced ServiceRequest resource might be compiled into recommendation +bullets. + +Although this Profile facilitates machine-readable encoding of the +potential ServiceRequests, the narrative Recommendation text may also +include conditional logic, e.g., if A is true then procedure X is +recommended; if B is true then procedure Y is recommended; else +procedure Z is recommended. This profile does not yet model this logic +in the coded recommendations; as a placeholder, the condition text could +be included in ServiceRequest.note, but this does not support +automated tooling. In this example scenario, all three procedures would +be included as referenced ServiceRequest resources (with status = draft, +as described above) and the referring physician would apply the logic in +the narrative to decide which to activate (by setting the status to +active), if any. + +#### 6.7.3.9 Communications + +This information is included in the body of the report, in part for +medicolegal purposes. If future HIT infrastructure handles tracking such +communications directly in the EMR, the practice of using the diagnostic +report to implement such accountability and tracking might change, but +for now it is expected to persist. + +This information may also support performance metrics such as the speed +with which the Referring Physician is notified of key clinical results +or other conformance to best practices for patient safety and quality of +care. + +The corresponding section narrative text may be created by concatenating +the .text contents for each of the referenced Communication resources. +This narrative often appears at the bottom of the report under the +Impressions and Recommendations. + +#### 6.7.3.10 Signature + +**Signature** of the report shall be encoded as a Provenance +resource. + +- Provenance.target shall reference the DiagnosticReport resource. (TODO + should it reference all the resources that would go in the bundle, or + is there a more efficient way to do this? Need to list the other + resources that were created as “components” of the report, but not + everything that goes in the bundle. So the observations and + conclusions would be referenced, but not the patient or + servicerequest) + +- Provenance.signature.type shall have a value of ProofOfApproval. + +- Provenance.agent.who and Provenance.signature.who (or + Provenance.signature.onBehalfOf) shall be compatible with the person + identified in DiagnosticReport.resultsInterpreter. See also Section + 6.7.3.0. + +While the DiagnosticReport does not reference Provenance resources, such +as the one containing the digital signature, the relevant Provenance +resources may be obtained with a query like: + +- GET \[base\]/Provenance?target=DiagnosticReport/12345 + +Relevant Provenance can also be included in the response bundle when +querying the DiagnosticReport in the first place using \_revinclude: + +- GET \[base\]/DiagnosticReport?\[search + parameters\]&\_revinclude=Provenance:target + +Note: Some resources include a .relevantHistory element that documents +prior clinical states of the resource via references to prior +corresponding Provenance resources. The “current” Provenance cannot be +so referenced since it cannot exist until after the current version of +this “target” resource has been created. + +Narrative text for the signature typically appears at the bottom of the +report text with a statement in a form similar to "This report was +digitally signed by Dr. X at \ on \". + +Preliminary (“unsigned”) reports may involve a DiagnosticReport resource +being made available which references a +DiagnosticReport.resultsInterpreter, but is not the target of a +Provenance resource with a .signature.type of ProofOfApproval. + +In the unprofiled DiagnosticReport resource, the signature appears to be +implicit. It is left to receivers to presume that if the report status +is final and there is an interpreter listed, that means that +practitioner approved the content of the report at some point in time. + +#### 6.7.3.11 Human-Readable Form + +The fully rendered human-readable form of the diagnostic report shall be +encoded in the DiagnosticReport.text attribute. This attribute +establishes a robust baseline representation of the report content. +Additional optional representations are described in 6.7.3.11.1. + +Per the [FHIR guidance for .text narrative +attributes](https://www.hl7.org/fhir/narrative.html#Narrative), the +.text narrative should support human-consumption as a fallback from +parsing the resource; structured data should not generally contain +information of importance to human readers that is omitted from the +narrative. Accordingly, to the extent that the DiagnosticReport +attributes described in Sections 6.7.3.2 through 6.7.3.9 are present +with content, corresponding sections shall be present in the .text +narrative. + +> Note 1. As a Narrative attribute, the content of .text is encoded in XHTML with [additional FHIR constraints](https://www.hl7.org/fhir/narrative.html#Narrative). +> +> Note 2. The [IHE Interactive Multimedia Report (IMR) Profile](https://profiles.ihe.net/RAD/IMR/) also constrains the content of the diagnostic report. + +- Sections shall be defined using \ tags. + +- Each \ tag shall have an ‘id’ attribute with a unique value + assigned to the section. + +- Each \ tag shall have a ‘class’ attribute with a code drawn from + Table 6.7.3.11-1, and formatted as \\|\. + This class code facilitates extraction of section text by report + consumers. + +- Each \ section shall contain a human readable title reflecting + the code meaning for the section. The title may be localized and/or + translated. The title may be enclosed in a header tag. + +- Each \ section may contain HTML 4.0 Text, List or Table elements + to organize content within the section + +- Each \ section may contain the ‘narrativeLink’ or ‘originalText’ + extension to link between data and narrative text. See + https://hl7.org/fhir/R5/narrative.html#linking for details and an + example. + +See Figure 6.7.3.11-1 for an example of the use of \ tags that +shows two sections, one for Finding and one for Impression. The Finding +section uses simple paragraph tags \ to separate multiple contents. +The Impression section uses an unordered list. This is not an example of +a full report. + +``` xhtml +"text" : { +"status" : "generated", +"div" : "\
+ +\
+\Findings:\ +The imaged portion of a thyroid gland is unremarkable. Prominent or +mildly enlarged mediastinal and bilateral hilar lymph nodes measure up +to 1.2 x 0.8 cm in the right paratracheal station (2:12) , 2.3 x 1.4 +cm in the subcarinal station (2:18), and 1.4 x 0.9 cm in the right +hilar stations (2:16). No significant axillary lymphadenopathy is +detected. The esophagus is unremarkable. The thoracic aorta is normal +in caliber with a typical 3 vessel takeoff from the arch. The +pulmonary arterial trunk is normal in caliber. The heart is normal in +size without pericardial effusion. +\

+Within the pulmonary parenchyma, there is diffuse peribronchovascular +nodular and ground-glass opacities becoming confluent in the right +middle (601:52) and left upper (601:65) and lower lobes (601:72) +consistent with multifocal pneumonia. There is a small left and trace +right pleural effusion. No pneumothorax is present. There are no +suspicious masses or pleural abnormalities. +\

+ +… + +\ +\

+\Impression:\ +\ +\Multifocal pneumonia involving the right middle, left upper and +left lower lobes with small left and trace right pleural +effusions.\ +\Central mediastinal lymphadenopathy is likely reactive.\ +\ +\ +\" +}, +``` + +**Figure 6.7.3.11-1: \ Section Example** + +Per FHIR guidance, all coded content of the diagnostic report that is +relevant to a human reader should be present in the .text rendering. + +The .text may also contain additional information which is not yet +modelled in the coded form of the report. Some practices include links +or references at the bottom of the report to educational material that +may be helpful to the patient and/or referring physician to understand +the impressions and/or recommendations. + +**Table 6.7.3.11-1: Section Codes** + + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Code Value

+
+

Coding System

+
+

Code Meaning

+
+

Notes

+
55115-0LNOrder
11329-0LNHistory
55111-9LNProcedure
18834-2LNComparison
59776-5LNFindings
19005-8LNImpression
18783-1LNRecommendation
73568-8LNCommunicationThis code is defined as communication of critical findings. A more +general code may be needed since some communications do not involve +critical findings.
+ +##### 6.7.3.11.1 Presented Form + +Additional renderings of the report in other formats such as PDF, HTML, +or RTF, may be included as Attachments under .presentedForm. The +.presentedForm.contentType shall contain a MIME code indicating +the format of the content. + +Since additional renderings are optional, DiagnosticReport consumers may +wish to refer to the `.text` rendering first. If present, renderings in +`.presentedForm` are typically targeted at the human readers (physicians, +patients), and the Report Creator may generate and include them to +address some of the different roles and goals described in RAD TF-1: +56.4.2.3 Use Case \#3: Report Presentation. A `.presentedForm` may also be +encoded in HTML, which may permit more sophisticated renderings than +what is in `.text`, which is more constrained. + +The additional renderings may contain graphical embellishments and/or +improved formatting for better readability, but should not introduce +clinical semantic content that is not present in the .text rendering. + +It is recommended that the `Attachment.title` for each presented form +attachment be populated to facilitate the recipient being able to +distinguish between multiple presented forms and select an appropriate +one. + +In addition to the rendered report in .text, and the presented form in +.presentedForm, the Report Creator may choose to reference Composition +resources in DiagnosticReport.composition to provide additional +arrangements and renderings of the imaging report content. See RAD TF-1: +56.4.1.4 for further discussion of Composition. + +##### 6.7.3.11.2 Resources.text + +Every FHIR Resource, being a child of the DomainResource, includes an +optional .text attribute which, if present, contains a text summary of +that resource instance for human interpretation. In the context of the +imaging diagnostic report, these can be useful components for the +construction of the human-readable form of the entire report. + +Each ImagingStudy resource referenced in DiagnosticReport.comparison +could have a one-line description of the study in ImagingStudy.text. +Each Observation resource referenced in DiagnosticReport.results could +have a brief text rendering of the observation in Observation.text. + +As noted above, many of these pieces of narrative text are good +candidates to be generated automatically from the coded content of the +resource itself. Some report consumer applications will sometimes find +the .text attributes a useful source of text for certain purposes, such +as presenting a specific component of the report, or populating part of +an HL7 V2 message segment. + +The .text.status is required to be present and contains codes that +describe the extent to which the semantic content of .text covers or +exceeds the coded content of the resource. See + + +For resources, such as Patient, that are used widely beyond the scope of +the diagnostic report, it the content of .text may or may not be well +suited to direct copying or concatenation without some processing. + +#### 6.7.3.13 Bundle Resource Usage + +The DiagnosticReport resource, like most FHIR resources, encodes +references to other associated resources. Handling collections of +related resources is typically done with the Bundle resource using one +of several bundle types and handling patterns. + +As shown in the RAD-141 (Store Multimedia Report) transaction, when the +report is initially created and stored, a transaction bundle +(Bundle.type=transaction) is used to POST the newly created resources +(DiagnosticReport, ImagingSelection, etc) as an integral set to be +processed together and created on the server. For these new reporting +resources, the Report Creator is typically the “source of truth”; i.e. +the information it provides is definitive. Other resources are +referenced by the DiagnosticReport but already existed prior to +reporting; for example, the Patient that is the .subject, or the +Practitioner that is the .resultsInterpreter. These are not expected to +be in the transaction bundle during creation since they do not need to +be created and other systems are the source of truth for those +resources. Some resources, such as the ServiceRequest referenced in +.basedOn and the ImagingStudy referenced in .study, are in a grey zone +where they might typically be expected to exist prior to creation of the +report but there may be situations where they are being “backfilled” by +the Report Creator. In such cases, they may be included in the +transaction bundle to be created conditionally as indicated by the +Bundle.entry.request.ifNoneExist element. + +As shown in the RAD-143 (Find Multimedia Report) transaction, when +querying for a report, a searchset bundle (Bundle.type=searchset) is +returned from the query. By default, the bundle contains matching +DiagnosticReport resources and no referenced resources. The \_include +and \_revinclude parameters can be used to have the searchset bundle in +the response also contain other referenced resources. (See +). + +Although out of scope for this profile, a future Export Imaging +Diagnostic Report transaction may be created to handle the need to send +DiagnosticReport resources to systems that will not necessarily have +access to all the resources referenced in the DiagnosticReport (e.g., +because the recipient is outside the IT boundary of the sender). That +transaction will describe a push transaction that includes a “full set” +of referenced resources in the message bundle. + +# Annex B - Example Imaging Diagnostic Report Content + +These examples were prepared in support of the Imaging Diagnostic Report (IDR) Profile. TOLINK See Section 6.7.3 Imaging Diagnostic Report Encodings for the encoding specifications. + +This appendix provides some examples of report content, followed by some examples of encodings. This is a limited set of illustrative examples. Additional examples may be available in IHE Connectathons. + +## B.1 Example Semantic Content + +### B.1.1 Example Order Semantics + +The following bullets provide a sample of content typical of order descriptions in an imaging report. + +- CT Sinus w/o Contrast + +- MRI Brain with and without Contrast + +- MRI Left Shoulder + +- MG of the Screening (Bilateral) *\* + +- PET/CT of the Skull Base To Mid-Thigh + +- US Guided Left Knee Injection + +- MRI Right Hip Arthrogram Including Cartigram Study + +- XR Chest 1 View + +### B.1.2 Example History Semantics + +The following bullets provide a sample of content typical to history descriptions in an imaging report. + +- Memory loss, 2 weeks history of dysbalance and lethargy + +- Right arm weakness; Difficulty expressing thoughts in writing beginning about 4-5 months ago. + +- Work related injury on September 21, 2015, assess for traumatic tear left rotator cuff with superior shoulder pain and weakness. + +- 24M with stent placement in the left main bronchus presents with right sided chest pain since 9am + +- A 52-year-old with hemoptysis. Right middle and lower lung zone consolidation. Please evaluate. + +- Spiculated right upper lobe lesion. The patient declined biopsy for follow-up. If increase in size would consent to biopsy. + +- Shortness of breath, pulmonary opacity on CXR +- Left knee pain. Semimembranosus bursitis. +- Follow-up pleural effusion +- Sinusitis. + +- Routine. *\* + +### B.1.3 Examples Procedure Semantics + +The following bullets provide a sample of content typical to procedure descriptions in an imaging report. + +- Axial PD FS, coronal PD FS and PD, sagittal T1 and PD FS imaging is performed through the left shoulder without contrast. + +- Sagittal and axial T1-weighted images, axial FLAIR images, axial diffusion weighted sequences, axial T2-weighted images and coronal gradient echo sequences of the brain were obtained. Following gadolinium administration axial and coronal T1-weighted images were obtained. + +- Thin slice axial images through the paranasal sinuses were obtained and reconstructed in the coronal and sagittal planes. + +- After intraarticular injection of diluted gadolinium in saline, axial T1 fat-sat, axial PD fat-sat, coronal T1 fat-sat, sagittal T1 fat-sat, axial oblique PD fat-sat, and coronal bilateral PD fat-sat images were obtained. This was followed by multiple acquisitions in the coronal and sagittal plane sequentially carried out with post processing and color mapping performed in order to obtain a T2 mapping cartigram study. + +- Agents: F-18 fluorodeoxyglucose. Dose: 17.2 millicuries IV. Prior to the administration of the radiotracer, a fingerstick blood glucose level was drawn, measured as 121 mg/dL. CT images for attenuation correction and anatomic localization followed by PET images from the skull base to the thighs were obtained. + +- A PET CT scan was performed from the level of the vertex of the skull to the proximal thighs following the administration of 18.6 mCi of FDG intravenously. + +- CT scan of the abdomen and pelvis was obtained with intravenous and without enteric contrast material. Coronal and sagittal reformats were provided. Dose reduction technique: The CT scan was performed using appropriate/available dose optimization/reduction techniques. + +- CT angiographic examinations of the head and neck were obtained utilizing 75 cc Isovue 370 intravenous contrast. Multiplanar MIP and 3D reformatted images were also created and reviewed. Stenosis measurements were performed based on NASCET criteria. CT scan performed using appropriate/available dose optimization/reduction techniques. + +- Head CT without intravenous contrast. Axial images through the brain were acquired from skull base to the vertex with 5 mm slice thickness. Images were reviewed in brain, subdural and bone window settings. + +- Single AP view of the chest + +### B.1.4 Example Comparison Semantics + +The following bullets provide a sample of content typical to comparison descriptions in an imaging report. + +- CXR from mm/dd/yyyy, CT Chest from mm/dd/yyyy (two weeks prior) + +- CT-PE of July 18, 2012 and limited CT chest from the declined biopsy of September 10, 2012. + +- Left knee ultrasound DATE. Left knee radiographs DATE. + +- Multiple, last dated August 8, 2023. + +- No previous exams are available for comparison. + +- None available. + +- None. + +### B.1.5 Example Findings Semantics + +The following bullets provide a sample of content typical to findings in an imaging report. +Many of these examples are organized as sets of related findings. + +- Finding set (MRI Cervical Spine) + + - The cervical cord appears normal in its size and signal characteristics. + + - The C2-3 and C3-4 discs are degenerated. + + - There is some mild bulging of the C3-4 disc. Neither level demonstrates central or neural foraminal narrowing. + + - There has been prior fusion from C4 through C7 in good alignment and position. An anterior screw and plate device is present. + + - At C4-5 and C5-6 there is no recurrent central or neural foraminal narrowing. + + - At C6-7 there is mild bilateral bony neural foraminal narrowing without central canal compromise. + + - The C7-T1 level appears unremarkable. + +- Finding Set (PET-CT) + + - A right lower breast mass is seen measuring approximately 6.2 x 1.6 cm in transverse dimension with SUV max measuring up to 4.2. The patient has had prior bilateral axillary node dissections. There is no current adenopathy in the axilla bilaterally by size criteria or metabolic activity. There is no adenopathy in the mediastinum or hilum similarly. + + - No pulmonary nodules or masses are identified. However, moderate right and small left perfusions are seen with low-level metabolism, SUV max measuring up to 3.0. + + - Diffuse thoracic esophageal hypermetabolism is noted. + +- There is a non-specific subpleural nodule in the right lower lobe which measures 2mm in diameter (Se 3, Im 72). + +- A smaller enhancing extra-axial mass more suggestive of atypical meningioma is seen overlying the right mid temporal lobe measuring 1.3 x 0.6 CM. (Axial series 12 image 26). + +- There is no significant end vessel ischemic small vessel disease. + +- There is no acute infarct seen. No intracranial hemorrhage is recognized. + +- MUSCLES AND TENDONS: The gluteal tendons are intact. The hamstring tendon origins are intact. + +- No compressive mass within the carpal tunnel. + +- Moderate extensor carpi ulnaris tendinosis. There is fluid reflective of tenosynovitis in the second and third extensor compartments as well along the region of the extensor digitorum tendons. + +- Moderate amount of fluid in the radiocarpal and midcarpal wrist compartments. + +- Mild dorsal angulation of the distal radius reflective of the fracture. + +- Evidence of edema in the central and volar aspect of the ligament. Edema extends into the volar radiocarpal ligaments. The pattern is reflective of a volar injury and partial-thickness tear in this region. There is no complete tear. There is no DISI deformity. + +### B.1.6 Example Impression / Conclusion Semantics + +The following bullets provide a sample of content typical to impressions in an imaging report. + +In some cases, a set of impressions for a particular type of exam are provided as a group to get a sense of the ordering and grouping patterns. Some impression sentences encompass multiple Conditions. Some impressions are shown broken down into more codable components. + +When the imaging clinician has interposed a recommendation amongst the impressions, it has been highlighted here {underlined between braces}. + +As an exercise to explore the suitability of the specification, a sample encoding \[shown in square brackets\] is provided for some impressions. Also, the encodings do not always capture 100% of the intended semantics and nuances of the radiologist. + +- Findings suggesting left peripheral lung base pulmonary infarct. + + - \[Condition.code = (64662007, SCT, "Pulmonary infarct"), + .bodyStructure.includedStructure.structure = (10024003, SCT, "Structure of Lung Base"), + .bodyStructure.includedStructure.laterality = right, + .bodyStructure.includedStructure.qualifier *=* (14414005,SCT,“Peripheral)*,* .likelihood = may represent\] + +- Impression Set (Abdomen US) + + - Fatty infiltration of the liver. + + - Small left pleural effusion. + + - Distended inferior vena cava and hepatic veins, findings consistent with congestive heart failure. + + - \[*code distended veins as observations, code CHF as Condition with the observations referenced from .evidence, and .likelihood is high\]* + +- Impression Set (XR Foot, Ankle, Tibia/Fibula, Knee) + + - Acute nondisplaced fractures of the proximal tibia and fibula. + + - Acute fracture of the distal fibular diaphysis. + + - Intact intramedullary nail fixation hardware. + + - *\[TODO Create an observation code of "intact" for application to any given anatomy, device, (or intervention/modification?) Or should this be coded as a set of negations: no loosening, breakage, protrusion or other visible complication of the nail fixation hardware?\]* + +- Impression Set (MRI Hip) + + - Moderate right hip osteoarthritis, with labral tearing and para labral cyst formation. + + - \[Condition.code= (396275006, SCT, "Osteoarthritis"), + .bodyStructure.includedStructure.structure= (24136001, SCT, "Hip joint"), + .bodyStructure.includedStructure.laterality=right, + .severity=moderate\] + + - \[Condition.code=(202336002, SCT, "Acetabular labrum tear"), + .bodyStructure.includedStructure.structure= (182439007, SCT, "Acetabular labrum"), + .bodyStructure.includedStructure.laterality=right\] + + - \[*Need code for para labral cyst*, + .bodyStructure.includedStructure.structure= (182439007, SCT, "Acetabular labrum"), + .bodyStructure.includedStructure.laterality=right\] + + - Chronic partial-thickness tears of the gluteus minimus and medius with small overlying greater trochanteric bursal fluid. + +- Impression Set (CT Neck, Chest, Abdomen/Pelvis) + + - No acute abnormality in the neck, chest, abdomen, or pelvis. No pathologically enlarged lymph nodes. + + - Multiple peribronchial bilateral pulmonary nodules, measuring up to 5 mm in the left lower lobe, likely infectious/inflammatory. + + - *\[… (786838002, SCT, "pulmonary nodule (disorder not finding) … how to code size generalization, likely etiology (infections/inflammatory) …\]* + + - No active GI bleed. + + - Mesenteric vessels are patent without evidence of end-organ ischemia. + +- Impression Set (MRI Brain, MRI Cervical Spine) + + - No evidence of acute infarction, hemorrhage, or a mass lesion. Chronic changes as described above. + + - A 1.1 cm focus of enhancement within the left parietal bone that does not demonstrate any cortical destruction or any other destructive features. There is a lucency at this site on the previously performed head CT. It is favored to represent a **venous lake**. + + - Congenitally small central canal from C3/C4 down to C5/C6 level. + + - Moderate to severe degenerative changes of the cervical spine as described above and summarized below. + + - At C3/C4, moderate central canal stenosis with flattening of the ventral surface of the cord. Moderate left neural foraminal stenosis. + + - At C4/C5, moderate central canal stenosis with flattening of the ventral surface of the cord. Moderate to severe left neural foraminal stenosis. + + - At C5/C6, moderate bilateral neural foraminal stenosis. + + - See below + + - At C6/C7, moderate right neural foraminal stenosis. + + - \[Condition.code =(371000119109, SCT, "Stenosis of intervertebral foramina"), + .bodyStructure.includedStructure.structure= (281875002, SCT, "C6/C7 intervertebral foramen"), + .severity=Moderate, + .bodyStructure.includedStructure.laterality=right\] + +- Impression Set + + - Prominent bilobed paramedial extra-axial **mass** along the convexity centered at the level of the posterior frontal and anterior parietal lobes with prominent posterior dural tail and occlusion of the adjacent superior sagittal sinus. Prominent surrounding reactive edema, left greater than right. Mild lateral shift but no herniation. Smaller extra-axial mass overlying the right mid temporal lobe. + + - \[Prominent bilobed (SHAPE) paramedial extra-axial (LOC) **mass** + + - along the convexity (LOC) + + - centered at the level of the posterior frontal and anterior parietal lobes (LOC) + + - with prominent posterior dural tail (SHAPE) + + - and occlusion of the adjacent superior sagittal sinus (LOC?). + + - Prominent surrounding reactive edema (RELATED CONDITION & LOC), left greater than right (SEVERITY?). + + - Mild lateral shift but + + - no herniation. + + - Smaller extra-axial mass (RELATED CONDITION & SHAPE) + + - overlying the right mid temporal lobe (LOC).\] + + - Atypical meningioma including hemangiopericytoma or variant or malignant subsidence of meningioma. Other less likely considerations include extra-axial dural based metastasis, lymphoma and less likely solitary fibrous tumor. + +- Impression Set + + - There is mild supraspinatus **tendinosis** with minimal articular sided **fraying** of the distal tendon and a 3 mm low grade **interstitial tear** at the distal attachment site. + + - There is marrow edema within the distal clavicle. There is a small AC joint effusion with mild pericapsular edema. This may represent mild stress related change of the AC joint versus a grade 1 sprain of the AC joint. There is no elevation or fracture of the distal clavicle. + + - There is no occult fracture or bone contusion. No malalignment of the osseous structures. + + - The age of injury is indeterminate. + +- There is a metastasis located within the right temporal lobe surrounded by a moderate size area of vasogenic edema. {Further evaluation with an enhanced MRI examination of the brain is recommended.} There are large confluent right hilar/parahilar and mediastinal metastases located within the chest. There is a complete atelectasis/consolidation of the right upper lobe (drowned lung). There are numerous metastases located within the peripheral portions of both lungs. There are multiple hepatic metastases. Please see report. + +- Impression Set + + - Complete full-thickness disruption of the anterior cruciate ligament. + + - Associated osseous contusion of the lateral condylar patellar sulcus: Pivot shift injury. + + - Grade 1 MCL complex injury. + + - No other associated injury identified *\* + +- Impression Set + + - Hydrocephalus without evidence of obstructing mass lesion. Acute hydrocephalus cannot be excluded since there are no prior studies available for comparison. Extensive chronic white matter changes may mask transependymal CSF edema. {Correlate with short-term followup to exclude acute hydrocephalus. Correlate with clinical symptoms to exclude normal pressure hydrocephalus.} + + - Chronic white matter changes. + + - Cerebral atherosclerosis. + +- Impression Set + + - Markedly abnormal multifocal hypermetabolic predominantly osteosclerotic lesions scattered throughout the axial and proximal appendicular skeleton consistent with wide spread osseous metastases + + - Right lower breast mass that appears hypermetabolic. {Please correlate with mammography and consider biopsy if indicated.} Recurrent disease is a consideration. + + - Indeterminate bilateral pleural effusions and ascites with low-level metabolism. Consider thoracentesis and evaluation of fluid for malignancy if clinically indicated. + + - Diffuse thoracic esophageal uptake. This pattern can be seen in patients with esophagitis. Please correlate clinically. + +- Spiculated mass within the posterior segment of the right upper lobe has increased minimally in size from September 2012, now with maximal dimension of 2cm versus 1.6cm previously. Radiographic staging of this presumed malignancy is T1a N0. No new pulmonary nodules and no findings of metastatic disease. + +- Impression Set (CTA Chest) + + - Moderate pericardial effusion with apparent mass effect on the right ventricle, leftward bowing of the intraventricular septum, a contrast level within the IVC, and severe reflux of contrast into the hepatic veins and right lobe parenchyma are highly suggestive of tamponade physiology. Pericardial enhancement suggests pericarditis as etiology. + + - No aortic dissection or intramural hematoma. + +- Impression Set (Lung Cancer screening Chest CT) + + - Lung-RADS CATEGORY: 2/S. Multiple pulmonary nodules. The dominant solid nodule is located in the right middle lobe and has a mean size of 5 mm (series 3, image 285). The category-determining solid nodule has a very low likelihood of becoming a clinically active cancer, due to size and/or lack of growth. + + - There are potentially significant incidental finding(s): thyroid lesion, incompletely characterized by CT + + - *\[how to code "incompletely characterized by CT"? Or is that narrative limitations of study and coding is less important?\]* + + - {RECOMMENDATIONS: Continue annual Lung Cancer Screening Chest CT examination if patient meets eligibility criteria.} + + - {RECOMMENDATION FOR POTENTIALLY SIGNIFICANT INCIDENTAL FINDING: Thyroid ultrasound, unless recently obtained} + + - Explanation of the Lung-RADS CATEGORIES CAN BE FOUND AT: HTTP://healthcare.partners.org/lung/rads.pdf + + - A clinically significant result was communicated on 2/--/202x 10:08 PM, Message ID ------. + +- Unremarkable CT evaluation of the paranasal sinuses. No obstructive pathology is seen. + +- (Chest X-ray) No acute cardiopulmonary process. + +- (MRI Brain) No acute or subacute infarct, mass effect, or acute intracranial hemorrhage. + +- Impression Set (CT Head) + + - No acute intracranial findings. + + - Mild left parietal scalp swelling and contusion. No acute calvarial fracture. + +- Impression Set (Screening Mammogram) + + - No mammographic evidence of malignancy in either breast. + + - {Annual screening mammography is recommended.} + + - BI-RADS 1 NEGATIVE \[(397140005, SCT, "Mammography assessment (Category 1) – Negative")\] + + - *\[This is an example of the rare case where .conclusionCode fits well. Should we also allow .conclusionCode and make consumers look in more places all the time? Or model it as an Observation?\]* + + - The patient will be notified of the results and recommendations. + + - *\[Look into coding intended, not attempted/completed, communications\]* + +- Impression Set (OB US) + + - 24 y.o. G3P2 at 21 weeks by 18 week ultrasound with reassuring fetal anatomic survey. Ms. X has a significant psychiatric history and is maintained on Lithium with good effect; she reports her mood is stable and she is in close contact with her psychiatrist. We reviewed the plan for a fetal echocardiogram and a referral was placed. + + - *\[much of the above likely should be in other sections\]* + + - Worksheet finished by ---- -----, sonographer on 1/--/202- 1:2-:5- PM. + + - *\[Such workflow/provenance probably belongs in Procedure?\]* + +- No evidence of acetabular labral tear or detachment. There is no high-grade chondral loss or delamination. + +- Very dense breasts without comparison studies limiting sensitivity. Comparison to previous mammograms would be helpful to assure stability of dense parenchymal pattern. + +- No active disease in the chest. + +### B.1.7 Example Recommendation Semantics + +The following bullets provide a sample of content typical to recommendations in an imaging report. + +- Referral to the DAP service is recommended. The lesion is amenable to CT guided biopsy. + +- Further evaluation with an enhanced MRI examination of the brain is recommended. + +- Recommend further evaluation with dedicated breast imaging at XXX Breast Imaging Center by calling xxx-xxx-xxxx to schedule an appointment. + +- Please correlate with mammography and consider biopsy if indicated. + +- Annual screening mammography is recommended. + +- Correlate with short-term followup to exclude acute hydrocephalus. Correlate with clinical symptoms to exclude normal pressure hydrocephalus. + +- Continue annual Lung Cancer Screening Chest CT examination if patient meets eligibility criteria + +- Recommendation for potentially significant incidental finding: Thyroid ultrasound, unless recently obtained + +- Recommend discussion of X with the patient. + +### B.1.8 Example Communication Content + +The following bullets provide a sample of content typical to descriptions of communications in an imaging report. + +- Findings discussed with Dr. REFERRING at 1630 hrs + +- Telephone message was left at Dr. DAVID LIVESEY office at the time of dictation. + +- A clinically significant result was communicated on 2/19/2024 10:08 PM + +## B.2 Example Usage + +## B.2.1 Presenting Comparison Studies + +A report viewer might offer to display studies used as comparisons in the report. + +- GET [baseURL]/DiagnosticReport/X?$elements=comparison +- (Receive ImagingStudy references; invoke display) + +## B.2.2 Ordering Recommended Followup + +A clinical workstation might help the referring physican to place an order for the followup PET scan recommended in the report by the radiologist. + +- GET [baseURL]/DiagnosticReport/X?$elements=recommendation +- (Receive ServiceRequest references; invoke ordering tool to finalize and place) +- Help the referring physician select one or more of the recommended ServiceRequests and complete additional details + +## B.2.3 Applying Relevant Clinical Guidelines + +A clinical workstation might help the referring physician to identify current clinical guidelines applicable to the conclusions identified in the report. + +- GET [baseURL]/DiagnosticReport/X?$elements=conclusionCode +- (Receive Condition & Observation references) diff --git a/input/pagecontent/volume-4-eu.md b/input/pagecontent/volume-4-eu.md new file mode 100644 index 0000000..5d01a89 --- /dev/null +++ b/input/pagecontent/volume-4-eu.md @@ -0,0 +1,9 @@ +# 11 Regional Extensions for IHE Europe + +The regional extensions documented in this section shall be used in conjunction with the definitions of integration profiles, actors and transactions provided in Volumes 1-3 of the IHE Radiology Technical Framework. This section includes extensions and restrictions to effectively support the regional practice of healthcare in the European Union. + +## 11.1 Imaging Diagnostic Report (IDR) + +### 11.1.1 TODO IDR + +... diff --git a/input/pagecontent/volume-4-jp.md b/input/pagecontent/volume-4-jp.md new file mode 100644 index 0000000..9008b43 --- /dev/null +++ b/input/pagecontent/volume-4-jp.md @@ -0,0 +1,10 @@ + +# 10 National Extensions for IHE Japan + +... + +## 10.6 Imaging Diagnostic Report (IDR) + +### 10.6.1 TODO IDR + +... diff --git a/input/pagecontent/volume-4-us.md b/input/pagecontent/volume-4-us.md new file mode 100644 index 0000000..b03770b --- /dev/null +++ b/input/pagecontent/volume-4-us.md @@ -0,0 +1,19 @@ +# 5 National Extensions for IHE United States + +... + +## 5.2 Imaging Diagnostic Report (IDR) + +The HL7 International - US Realm Steering Committee has published a US Core FHIR IG that includes DiagnosticReport. The IG is intended to reflect the requirements in the United States Core Data for Interoperability (USCDI) specification that is published by the Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (hereafter ASTP, formerly ONC). + +[Version 7.0.0 of the US Core FHIR IG](http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core) was published on May 8, 2024. + +[Version 5 of the USCDI](https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi#uscdi-v5) was published on July 16, 2024. + +Both of the above specifications are being updated on an annual basis. + +The IHE IDR Profile requires various coded FHIR content to support capabilities like those described in Use Case #4 Report Processing (See RAD TF-1:X.4.2.4). Such coding is not required by the US Core but is not prohibited. Thus, DiagnosticReports that conform to this profile support such use cases while still being largely compatible with the US Core and its use cases. + +### 5.2.1 TODO IDR + +... diff --git a/publication-request.json b/publication-request.json index 311f816..ee3c784 100644 --- a/publication-request.json +++ b/publication-request.json @@ -2,7 +2,7 @@ "package-id" : "{pid} -- ihe.domain.profile", "version" : "{version to release}", "path" : "{path} -- https://profiles.ihe.net/Domain/Profile/1.0.0", - "milestone" : true | false, + "milestone" : "true | false", "status" : "release", "sequence" : "Releases", "desc" : "{desc of release} (optional)", diff --git a/sushi-config.yaml b/sushi-config.yaml index 78f9bf9..373f250 100644 --- a/sushi-config.yaml +++ b/sushi-config.yaml @@ -7,12 +7,12 @@ canonical: https://profiles.ihe.net/RAD/IDR version: 0.0.1-current name: IHE_RAD_IDR title: "Imaging Diagnostic Report" -description: The Imaging Diagnostic Report (IDR) profile enhances the reporting infrastructure by using FHIR-based data exchange to improve imaging interpretation, communication of results, and subsequent clinical workflows and analysis. +description: The Imaging Diagnostic Report (IDR) profile defines a FHIR-based encoding of imaging report content to improve the communication of imaging results and recommendations, and facilitate subsequent clinical workflows and practice. The primary intended scope is common radiology specialties using common modalities. releaseLabel: ci-build #releaseLabel: ballot #releaseLabel: trial-use #releaseLabel: release -#date: 2022-01-02 +#date: 2025-08-02 status: draft publisher: ## Find your domain contact on the https://www.ihe.net/ihe_domains page @@ -25,10 +25,15 @@ contact: - system: email value: radiology@ihe.net license: CC-BY-4.0 -fhirVersion: 5.0.0 +fhirVersion: 6.0.0-ballot3 +## Try -cibuild? + +## dependencies: +## hl7.fhir.r6.core: current + jurisdiction: 'http://unstats.un.org/unsd/methods/m49/m49.htm#001' #copyright: IHE http://www.ihe.net/Governance/#Intellectual_Property -copyrightYear: 2023+ +copyrightYear: 2024+ parameters: # see https://confluence.hl7.org/display/FHIR/Implementation+Guide+Parameters @@ -52,12 +57,36 @@ parameters: # see https://confluence.hl7.org/display/FHIR/Implementation+Guide+ resources: # list every example here with a name, description and that exampleBoolean is true; These are used to populate the artifacts page, and are needed to eliminate build warnings # You may delay filling out this section until you approach publication as it is merely a nice to have and eliminates build warnings -- If you do this then you will need above the autoload-resources true - +# TODO pages: # itemize here each narrative page. Include assigned section numbers when appropriate. The order they appear here is the order they will appear in the TOC and on the next/prev navigation. index.md: - title: 1:XX IDR Home + title: 1:56 IDR Home + generation: markdown + volume-1.md: + title: 1.56 Imaging Diagnostic Report (IDR) + generation: markdown + volume-3.md: + title: 6.7 Imaging Diagnostic Report Content + generation: markdown + volume-4-us.md: + title: 5 National Extensions for IHE United States + generation: markdown + volume-4-jp.md: + title: 10 National Extensions for IHE Japan + generation: markdown + volume-4-eu.md: + title: 11 Regional Extensions for IHE Japan + generation: markdown + rad-Y1.md: + title: 4.Y1 Store Imaging Diagnostic Report + generation: markdown + rad-Y2.md: + title: 4.Y2 Query Imaging Diagnostic Report + generation: markdown + rad-Y3.md: + title: 4.Y3 Retrieve Imaging Diagnostic Report generation: markdown testplan.md: title: "Test Plan" @@ -74,6 +103,39 @@ pages: menu: Home: index.html + Volume 1: + Introduction: volume-1.html + Actors and Transactions: volume-1.html#561-idr-actors-transactions-and-content-modules + Actor Options: volume-1.html#562-idr-actor-options + Actor Required Groupings: volume-1.html#563-idr-required-actor-groupings + Overview: volume-1.html#564-idr-overview + Security Considerations: volume-1.html#565-idr-security-considerations + Cross Profile Considerations: volume-1.html#566-idr-cross-profile-considerations + Volume 2: + Store Imaging Diagnostic Report: rad-Y1.html + Query Imaging Diagnostic Report: rad-Y2.html + Retrieve Imaging Diagnostic Report: rad-Y3.html + Volume 3: + Imaging Diagnostic Report Overview: volume-3.html + Imaging Diagnostic Report: StructureDefinition-imaging-diagnosticreport.html + Patient (Subject): StructureDefinition-idr-patient.html + ServiceRequest (Order): StructureDefinition-idr-imaging-service-request.html + Condition (Patient History): StructureDefinition-idr-patient-history-condition.html + Observation (Patient History): StructureDefinition-idr-patient-history-observation.html + Procedure (Patient History): StructureDefinition-idr-patient-history-procedure.html + FamilyMemberHistory (Patient History): StructureDefinition-idr-patient-history-family-member-history.html + Procedure: StructureDefinition-idr-imaging-procedure.html + ImagingStudy: StructureDefinition-idr-imaging-study.html + Comparison: StructureDefinition-idr-imaging-study.html + Findings: StructureDefinition-idr-observation.html + Condition (Impression / Conclusion): StructureDefinition-idr-impression-condition.html + Observation (Impression / Conclusion): StructureDefinition-idr-observation.html + ServiceRequest (Recommendation): StructureDefinition-idr-recommendation-service-request.html + Communication: StructureDefinition-idr-communication.html + Volume 4: + National Extensions for IHE United States: volume-4-us.html + National Extensions for IHE Japan: volume-4-jp.html + Regional Extensions for IHE Europe: volume-4-eu.html Artifacts: artifacts.html Other: Test Plan: testplan.html