View source for Imaging Diagnostic Report (Phase II) - Proposal

==1. Proposed Workitem: Imaging Diagnostic Report – Phase II==
* Proposal Contributors: Kevin O’Donnell, Tarik Alkasab
* Workitem Editor: Kevin O’Donnell 
* Domain: Radiology

===Summary===
Imaging Diagnostic Report (IDR) left detailed encoding of the Findings section Out Of Scope for Phase I. Addressing that would support more complete coding of report data, a variety of automation functions for radiologists, and better clinical databasing. Also, work is needed to harmonize the IDR IG and the HL7 Europe Imaging Report IG motivated by EHDS.

The Findings work will primarily leverage the hierarchical Observation resource and Radelement/CDE work on finding "sets". The harmonization work will be primarily based on the two FHIR Implementation Guides (IGs) for IDR and the HL7 Europe activity.

An updated IDR Profile IG will be produced with revisions and more detail on Findings. A European National/Regional Extension may result for details that remain after convergence work. possible.

HL7 EU Imaging project members have expressed interest in harmonization. RSNA RadElement participants will be involved in review and possibly development.

Establishing international core Profiles with coordinated National Extensions as necessary is central to the value of IHE.

==2. The Problem==

The IDR Profile defines a FHIR encoding of an imaging diagnostic report. To meet scoping constraints, it focussed on a distributable report that enables automation and support functions for the primary customer of the report, the referring physician.  This involved profiling the structure and primary metadata and the impressions and recommendations sections in relative detail to facilitate clinical decision support, easier ordering of appropriate follow-up scans, application of relevant clinical guidelines, etc.

A detailed profiling of the Findings section of the report was deferred to “Phase II” since it is more complex, has a wider range of content, and arguably, serves a different primary customer, the subsequent radiologist/imaging clinician.  For the referring physician use case, virtually all finding content of interest is present in the Impression section. For the radiologist, coded finding content could provide significant value in terms of efficient workflow and report quality. See Use Case (below) for some target functionality.

A second challenge is the emergence of multiple imaging report specifications with conflicting requirements and guidance. A standardized, uniform, encoding/format for imaging reports is, of course, highly desirable for systems that receive, display, process, database, and implement automations based on those reports.   Creating and distributing reports with encoding variations increases implementation effort and reduces interoperability. 

It would be beneficial for the groups involved to meet together to harmonize key technical details, resulting in a core global specification with (hopefully minimal) national/regional extensions that allow implementations to more easily understand and handle unavoidable variations. Specifically, there have been discussions with members of the HL7 EU Imaging Report Working Group about the possibility of harmonization efforts.  

==3. Key Use Case==

===Imaging “Problem List”===
Tarik Alkasab has promoted the concept of an “imaging problem list” which consists of a compilation of the observations and conclusions from the imaging history of a given patient.  This would likely be something prepared for each study on the reading worklist to support the pending interpretation process by the imaging clinician.  A key premise is that many findings from prior reports represent details that the current imaging clinician should weigh in on or at least mention in the current report. Possible functions a coded “problem list” might facilitate include:
:* supporting protocoling of the current exam (views, scan range, contrast, technique) to facilitate effective follow-up of pertinent “problem list” items
:* preparing a concise summary of the patients imaging history for the imaging clinician
:* highlighting topics the imaging clinician has not commented on (completeness)
:* identifying and/or automatically performing current measurements to mirror prior measurements
:* plotting/presenting trends over time for certain details   
 
===EHDS/XtEHR Use Case===
Some of the differences in the HL7 EU Imaging specification are likely driven by interpreting particular data requirements in the European eHealth Network guidelines, which in turn are driven by a primary use case of cross-border request and retrieval of imaging studies and imaging reports by a health professional.  Confirmation and clarification of the use case will be a relevant part of harmonization and national/regional extension partitioning. E.g. the EU inclusion of all image-producing clinical specialities in scope, specifically including pathology, dental and surgery. 

==4. Standards and Systems==

:* IHE IDR Profile (Phase I)
:* HL7 EU Imaging Report IG 
:* RadElement/CDE (Clinical Data Elements) Sets
:** At a technical level, a key aspect of encoding findings is the clustering of related observations (e.g. the dimensions, volume, margins, shape, etc of a tumor). Significant work on the semantics of such clusters has already been done in the form of “CDE Sets” in the RadElement project at RSNA.

==5. Discussion==

:* There is some discussion underway in IHE Europe about publishing the HL7 EU specifications as IHE specifications

==5. Technical Approach==
''<This section describes the technical scope of the work and the proposed approach to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility. The Technical Committee may revise/expand this section when doing the effort estimation.>''

''<READ PROPOSER HOMEWORK IN '''[[Proposal_Effort_Evaluation#Proposer_Homework|Proposal Effort Evaluation]]''' FOR GUIDANCE ON POPULATING THE FOLLOWING SECTIONS >''

===Actors===
* No new actors anticipated. Would use actors in IDR.

===Transactions===
* (NEW) May finish fleshing out the Store/Query/Retrieve skeleton that appears in IDR Phase I.

===Profile===
* Use Case for Radiologist Findings History/Problem List
* Concept Section for Findings Information Model 
* Vol 4 for residual regional details

===Decisions/Topics/Uncertainties===
* Observation Resource usage to encode hierarchical finding sets.
* Various points of harmonization (See IDR-HL7EU comparison Sheet for starters)

==6. Support & Resources==
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''

''<Identify anyone who has indicated an interest in implementing/prototyping the Profile if it is published this cycle.>''

==7. Risks==
* Scope creep into broader imaging reports. 

''<List real-world practical or political risks that could impede successfully fielding the profile.>''

==8. Tech Cmte Evaluation==

Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* xx% for MUE
:* yy% for MUE + optional

Editor:
: Kevin O'Donnell

SME/Champion:
: TBA ''<typically with a technical editor, the Subject Matter Expert will bring clinical expertise; in the (unusual) case of a clinical editor, the SME will bring technical expertise>''