HealthManagement, Volume 12 - Issue 1, 2012
Radiology reports are the form of communication between radiologists and the referring clinical doctor. The referring clinical doctor sends a “radiology request card or letter”, which may be on paper or in electronic format. The IT system used for generating a radiology request is referred to as Ordercomms. Let us look at the clinical structure of a radiology request card/letter. The referring doctor provides some background clinical information (clinical symptoms/findings and any relevant blood tests). He/she would also provide a differential diagnosis or provisional diagnosis (if there is one at that stage). However, often it may not be possible to come to a differential diagnosis at that early stage, so the request card may simply describe the symptoms, e.g. “shortness of breath. Cause?” Finally the requesting doctor usually asks a clinical question.
Radiology Request Structure
If we were to implement a template for a radiology request card for Ordercomms, this is how it would be structured:
1. Patient related information
a. Name, DOB
b. Sex
c. Address
d.Unique ID
e. Patient location at request (i.e. inpatient or outpatient - and ward name/institution if inpatient)
2. Author of request information
a. Name
b. Grade/Role
c. Department/Specialty
d. Institution
3. Recipient Information
a. Name of Radiologist/Group
b.Department/Specialty
e. Institution
4. Investigation Requested
5. Clinical Information
a. Clinical symptoms/signs/results of investigations
b.Differential Diagnoses (if possible at the stage)
c. Clinical Question
When we look at this basic structure, we realise that whilst the first four groups are machine/computer readable, the final group (clinical information) is narrative and needs to be human readable. If we were to look for an IT document structure that would allow standard clinical practices to continue, we find HL7 CDA (Clinical Document Architecture) fulfils the architectural needs for Clinical Request cards. It has two parts: machine readable & human readable.
Clinical Context is Critical
Radiology reports are communication from radiologists back to the referring clinicians in response to the radiology request (the radiologist would have performed some imaging exams, & the report is the form of communication between radiologists and referring clinicians). Equally, if we were to look at the structure of a radiology report, we find a lot of similarities. Radiology reports would often describe the findings on the images.
They would come to a summary/conclusion, which would include responding to the clinical question in the request card. They would provide a differential diagnosis (if it is possible at that stage). They would also provide a recommendation if appropriate.
My own clinical structure for a radiology report is:
- Clinical Indication: This is my brief interpretation of the clinical requesting information.
- Findings: Description of the findings on the images.
- Conclusion & Differential Diagnosis: If it is possible to arrive at a conclusion & differential diagnoses at this stage.
- Recommendations: For example, referral to another department, further tests, etc.
It is however, important to remember that the clinical/narrative content within a report will vary very vastly depending on the clinical context and type of investigation. Sometimes a report that says a single word “normal” is perfectly adequate, and any additional words may not add any further clinical value.
Table 1: XDS/XDR Metadata Concepts
Radiology Report Structure
Hence, if we were to create a template for a radiology report, it would be as follows:
1. Patient Related Information:
a. Name, DOB,
b. Sex,
c. Address,
d. Unique ID
e. Patient location at Request (i.e. inpatient or outpatientand ward name/institution if inpatient)
2. Author of Radiology Report:
a. Name of reporter
b. Grade/Role
c. Department/Specialty
d. Institution
3. Recipient Information
a. Name of Referrer
b. Department/Specialty
c. Institution
4. Investigation Performed
5. Clinical Content (variable):
a. Clinical Indication
b. Findings on the images described,
c. Conclusion & Differential diagnoses
d. Recommendations
We suddenly find many similarities in the document structures between the two clinical documents - Radiology Request and Radiology Report - apart from the Clinical Content element. This kind of structure would fit with much of the clinical correspondence between specialties or even within specialties. Medicine is not maths and radiology reports are opinions based on certain information provided. Hence, radiology reports must provide a narrative content, within a structured machine-readable framework.
Figure 2: CDA Format
IT Documentation Structure
This must be kept in mind when speaking with vendors, who are looking into IT templates for radiology reports. RIS (Radiology Information System) is the IT system that generates radiology reports. CDA is the IT document structure being gradually adopted across the world by RIS vendors. CDA structure has three elements:
1.Machine Readable - patient, author, recipient, etc.
2. Human Readable - narrative
3. Coded Entries - optional and dependent on the document type. Coded entries are specific to a document type and are an important feature of CDA. Coded entries would be useful for populating certain fields for national registries. For example, radiation dose or radiology exams, TNM staging for cancer registries, certain fields for research purposes, fields for audit/finance etc. Coded entries could be intelligently incorporated into the CDA based radiology report by the RIS vendors.
Why do we Need CDA?
The question we ask ourselves is why do we need to adopt a standard document template like CDA? The simple answer is communication. We need to share the radiology reports generated in RIS with other IT systems used by the requester. Referrers may wish to read their reports in a variety of IT systems - Ordercomms (so that clinicians can track reports in the context of the requests they have made), PACS (so that clinicians can see reports in context of images), EPR (clinicians want to see radiology reports, radiology request and images in the context of other clinical documentations), GP Systems (for radiology requests coming GPs), etc.
Standard methodology for transfer of CDA documents (radiology reports) with other IT systems will very much depend on whether the transport is required within Information Governance (IG) boundaries or outside the IG boundaries. Where transport of documents is required to be within IG boundaries, XDS of IHE is the methodology. Any XDS consumer within an XDS domain - IG boundaries – Order Comms, PACS, EPR will be able to display these reports within an XDS framework. Outside the IG boundaries transfer of documents requires pointto- point transfer of individual documents - XDR of IHE is the global transport standard for this. Metadata required for both XDS and XDR should already be part of the CDA machinereadable data headers.
XDS/XDR Metadata Concepts
XDS/XDR metadata concepts are described in table 1, page 21 as an example which some are recommending for use in England, although this is still to be agreed nationally. Similar metadata structure will need to be agreed in different countries. The Netherlands has been more advanced than England with moving to a standardised XDS metadata set and you can find more information on that at this website: http://www.nictiz.nl/page/Nieuws?mod%5BNictiz_News_Module% 5D%5Bn%5D=2400.
Conclusions
Understanding CDA and XDS/XDR concepts are key to understanding why IT templates for radiology reports are required and also ensuring that the IT templates chosen are suitable for clinical practice. The key reason for requiring IT templates is to facilitate electronic report sharing between multi-vendor IT systems – the RIS and varied IT systems used by the referrers. Hence adoption of global standards for documents (HL7, CDA) and global standards for transport/access (XDR/XDS) is key in a multi-vendor IT systems environment.
