UK Imaging Informatics Group
Radiology Reports converted into DICO... PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Integration & Standards >
Message/Author
 Link to this message Neelam Dugar  posted on Wednesday, January 14, 2015 - 08:16 pm Edit Post Delete Post Print Post
I am exploring how Radiology Reports can be converted to DICOM SR and embedded in with the images within the DICOM study within the VNA.

This will required VNA to extract the following HL7 fields from the HL7 ORU message and convert them into the DICOM SR for the study

Intended Recipients of the Report—OBR28
Date and Time of Report—OBR22
Primary Reporter—OBR32 (name/ID/Specialty/Institution)
2nd Reporter—OBR33 (name/ID/Specialty/Institution)
Transcriptionist name-OBR34
Narrative Text of the Report—OBX5 of ORU
Abnormal Flag—OBX8 of ORU
Result Status—OBR 25 (Finalised-F & Addendum-C)

This will make VNA a truly independent entity.

Comments please.
 Link to this message Rene Spronk  posted on Thursday, January 15, 2015 - 07:53 am Edit Post Delete Post Print Post
The use of v2 ORU fields is highly dependant on the system that sends a report, IHE SWF may provide some general guidance.

In general I have to question your implicit assumption that reports need to be converted into DICOM SR. DICOM SR isn't actually very suited for 'reporting', it is meant to be used for 'measurements'. IHE requires the use of either text or PDF embedded in a CDA body (CDA Level 1, see the ITK specs for "NonCodedCDA" guidance). A true VNA will support XDS and as such the CDA document and the study will be linked by a shared metadata identifier, which could be order number or even study ID.

If there are any measurements/coded data that have an impact on the clinical interpretation of the images themselves, by all means use SR. For all other reporting, stay far away from it, especially if you'd ever like to share reports outside of the imaging department.
 Link to this message David Clunie  posted on Thursday, January 15, 2015 - 01:00 pm Edit Post Delete Post Print Post
Actually DICOM SR was explicitly intended for encoding radiology reports, particularly if authors took the time to add links to images and coordinates, but even if just plain text, or organized as headings. That is why it is called "Structured Reporting" and not something else. This was the case from the very beginning, and the reason that there are specific templates for such reports, which started out as IHE Simple Image and Numeric Report (SINR profile) and became TID 2000 (and later TID 2006). See:

http://wiki.ihe.net/index.php?title=Simple_Image_and_Numeric_Report
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_A.html#s ect_TID_2000
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_A.html#s ect_TID_2006

That said, they have not proven terribly popular for that purpose, and it turns out that radiologists seem neither enabled nor motivated to add links to regions on images when reporting, which undermines the value of SR.

Radiology reports in DICOM SR can of course be shared as ordinary DICOM instances (that aren't images) using XDS-I, so they are not called out as specific report formats in XDS-I in the manner of the plain text, CDA or PDF report formats.

Nor has CDA proven terribly popular for reporting either, yet, but that is the direction that folks want to go, and to that end DICOM Sup 155 is being developed, in the form of a CDA Implementation Guide to improve upon earlier efforts (as well as update the contents of PS3.20 that currently specify transformation of DICOM SR to CDA). See:

http://www.dclunie.com/dicom-status/status.html#Supplement155

David
 Link to this message Neelam Dugar  posted on Thursday, January 15, 2015 - 10:47 pm Edit Post Delete Post Print Post
Intended Recipients of the Report—OBR28
Date and Time of Report—OBR22
Primary Reporter—OBR32 (name/ID/Specialty/Institution)
2nd Reporter—OBR33 (name/ID/Specialty/Institution)
Transcriptionist name-OBR34
Narrative Text of the Report—OBX5 of ORU
Abnormal Flag—OBX8 of ORU
Result Status—OBR 25 (Finalised-F & Addendum-C)

Today RISes will send the above fields to PACS, where it will be stored in the PACS database--(rather than a structured report.) . These fields are very basic really and any RIS supplier will support them.

Current problems:
1. CD created from PACS does not have the report--they need to be burnt separately
2. Images sent via IEP need to send the report separately.
3. Images sent via DICOM push do NOT have the report with them
4. Images migrated at end of contract need separate migration of reports from RIS or PACS database.

Hence, I do think conversion of clinically useful HL7 ORU fields into DICOM SR at the time of image ingestion into VNA, is a very exciting prospect. It makes VNA image archive to be totally "vendor neutral"--without dependency on the database information.

I do think VNA is finding its rightful place
1. XDS support for Enterprise Archive
2. Back-up DICOM archive
3. Life cycle management
4. Fully clinically comprehensive, independent DICOM archive for migration purposes
 Link to this message Neelam Dugar  posted on Sunday, January 18, 2015 - 08:29 am Edit Post Delete Post Print Post
Thanks David and Rene for your comments. Much appreciated.

I was sent below comments by a PACS & VNA vendor. He confirms that PACS and VNA are able to convert Radiology Reports and Cancellation Reason into DICOM SR. However, it is important that the RIS vendor does support HL7 standards properly and the messages and fields are signed up between RIS vendor, PACS & VNA vendor and Customer.

Here is the content of his email (i have permission to post this)

"Hi Neelam,

I promised you to share our thoughts on this subjects.

Converting radiology reports into DICOM SR is not particularly a new approach, we already do this in our PACS for more than 10 years. The difference between that time and now is that currently there is an alternative in CDA. The trend seems to be that CDA is used for regular reports and DICOM SR for more specialist reports like dose or CAD.

However, not all PACS system do have support for CDA (yet), which means that DICOM SR would still be a sensible choice to make sure your VNA stays purely vendor neutral.
DICOM Part 20 defines a way to convert DICOM SR into CDA, so in a way you could look for an hybrid approach for the next coming years. You would store the reports as DICOM SR in your VNA, where you can retrieve them via WADO in the CDA formatting."

I do believe that a DICOM Archive--whether PACS or VNA which contains
1. DICOM SR for Radiology reports OR Reason for Cancellation
2. Updated clinically relevant DICOM tags updated by HL7 ORM fields
is essential for creating a "Clinically useful and Independent DICOM archive"
 Link to this message Robin Breslin  posted on Wednesday, January 21, 2015 - 05:09 pm Edit Post Delete Post Print Post
I think the point is to push PACS providers into completing the CDA developments...
.. and IOCM

The problem with fitting data items into data constructions that are 'temporary', or which were meant for other things, is that you will be living with those inconstancies in your data for a long time.

Neelam - you are very practical I know.
 Link to this message Neelam Dugar  posted on Thursday, January 22, 2015 - 06:48 am Edit Post Delete Post Print Post
PACS contains 3 components:
1. DICOM archive (standard based)
2. Database (which has the HL7 items--ORM, ORU and ADT updates)--Proprietary
3. Image display software
It is because of the proprietary PACS database:
a. the PACS display shows "corrected" clinical information and associated reports.
b. outbound images--for migration, DICOM push, CD creation etc will contain the corrected information.
Hence, the PACS database (proprietary) is very important for correct and complete information.

A DICOM archive like a VNA--- that corrects the DICOM tags, and stores the radiology reports/cancellation reason as DICOM SR from HL7 ADT, ORM and ORU information, makes the DICOM Archive really complete and comprehensive.
1. Migration from such a VNA does not rely on data held in the proprietary database.
2. Printing CDs or DICOM push from such a VNA will have correct complete information including the radiology report.

It is really up to VNA vendors how they want to sell themselves to customers,
a. about what added value they provide over and above PACS.
b. Advantages of a comprehensive and independent DICOM archive.
 Link to this message Neelam Dugar  posted on Thursday, January 22, 2015 - 06:55 am Edit Post Delete Post Print Post
Robin,
I take your point.

However, PACS support of PDF and CDA display is inevitable--I think. XDS consumers require PDF and CDA formats to be supported.

It would be foolish for PACS vendors not to look at native PDF and CDA display--particularly if they wish to continue with a philosophy of an Enterprise display software (and not just a software used by radiologists).
 Link to this message Shaun Smale  posted on Thursday, January 22, 2015 - 09:34 am Edit Post Delete Post Print Post
Neelam
you forget one very important thing required for an enterprise solution. The PACS, and any other applications, must have the ability to update any external copies of its data if structural changes are made to the primary copy. it is no longer adequate to correct the PACS database alone. The PACS (or other application) must have the ability to broadcast this change to all other applications, in particular a VNA, that hold a copy of this data and that can be directly accessed by a clinician. This can be achieved via IOCM. The PACS will determine which studies have changed (may be more than one) and send out a IOCM to deprecate all copies, it then must send a replacement with new Instance UIDs.
Global demographic changes must also be applied to all copies. Without these mechanisms (or manual equivalent) there is a small, but significant chance, that an erroneous, uncorrected copy of the data is used for clinical decision with detrimental results, while the PACS copy is fully corrected and safe. It goes without saying that the receiving applications (VNA) must act on the IOCM and demographic updates (via HL7).
 Link to this message Robin Breslin  posted on Thursday, January 22, 2015 - 11:09 am Edit Post Delete Post Print Post
Shaun - you're right of course (and I wondered how long before anyone explicitly mentioned IOCM).

I think the use of IOCM is really implicit in Dave Clunie's input. You can't have interoperability just by exchanging objects, you have to have the means to inter-operably manage those objects.

If I get time I am thinking of doing a quick survey of PACS and VNA vendors/products to see who does what with respect to CDA/IOCM. It's useful information in a world where users want plug and play interoperability.
 Link to this message Shaun Smale  posted on Thursday, January 22, 2015 - 11:45 am Edit Post Delete Post Print Post
Robin,
It easier to be an IOCM listener. Not so easy to develop the complex workflow to send out the IOCM and replacement images in strict conformance to the DICOM standard.
BridgeHead have implemented IOCM workarounds with two different PACS venders to allow them to depreciate studies in the VNA, and for the VNA to except the replacement studies (even with duplicate IUID and different structural content).
Happy to discuss our solution in more detail off-line.

Shaun

PS we also support CDA

Commercial interest declared
 Link to this message Neelam Dugar  posted on Thursday, January 22, 2015 - 09:24 pm Edit Post Delete Post Print Post
Thanks Shaun & Robin. Interesting discussion indeed :-)

1. DICOM image archive synchronisation between VNA & PACS requires IOCM
2. Patient Demographics need to be synchronised with PAS by both VNA & PACS via HL7 ADT
3. Exam related clinical information--exam description, referring clinician/specialty, & report information --HL7 ORM & ORU synchronisation with RIS for both VNA & PACS.

IOCM is important but so are ADT, ORM & ORU.

Shaun, does Bridgehead VNA convert the HL7 ORU into a DICOM SR so that a viewer displaying via WADO can display images and reports together?
 Link to this message Shaun Smale  posted on Friday, January 23, 2015 - 05:25 pm Edit Post Delete Post Print Post
Yes neelam,
BridgeHead's VNA fully supports DICOM SR. However we would recommend that HL7 ORU or CDA are converted to a XDS document and stored in the VNA. In either case they can be displayed using, DICOM, XDS and or WADO along with the images.

Shaun
 Link to this message Neelam Dugar  posted on Sunday, January 25, 2015 - 11:14 pm Edit Post Delete Post Print Post
Thanks Shaun.
Radiology reports, reason for cancellation and even radiology requests, if stored as DICOM SR within a VNA, allows:
1. Migration to happen from VNA without dependency on HL7 data in RIS
2. WADO display by a DICOM viewer will show radiology reports along with images --even if it is not XDS consumer
3. Burning onto CDs from VNA will include radiology report (and request) too

XDS with CDA/PDF are important for adding other o-logies into the VNA acting as an Enterprise Archive

Hence VNA has 3 important functions
1. DICOM Archive for Radiology-PACS back-up, migration tools etc
2. XDS registry & Repository--to include other o-logies for Enterprise Archive functionality
3. Rules based life cycle management
 Link to this message Neelam Dugar  posted on Friday, February 27, 2015 - 08:21 am Edit Post Delete Post Print Post
Perceptive/Acuo VNA & Fujifilm PACS--what are we doing:
1. DICOM archive--VNA will store DICOM images as our back-up archive (Fujifilm PACS is our primary archive)
2. VNA will convert the ORU message from Zillion RIS to DICOM SR reports, and will store them with images. Addendum reports will also be stored in VNA too.
3. ADT feeds from PAS will ensure that VNA and PACS is always in sync with PAS demographics
4. ORM and ORU feeds to VNA and PACS ensure that exam related information is always in sync with Zillion RIS.
5. Rules based Life-cycle management is within VNA. However, date of culling is displayed on the Fujifilm PACS frontend for clinical users to see and "extend the date of culling". They cannot reduce the date. They could do this for slow growing tumours etc
6. Our PACS managers will be able to migrate image data from VNA-- we will ensure that DICOM SR can be migrated as well.
7. XDS Registry and Repository function is within VNA (Zillion RIS provides radiology reports, requests etc as pdf doc to the VNA--linked to DICOM images by XDS folders)
8. XDS Consumer will be from Fujifilm.
 Link to this message Neelam Dugar  posted on Friday, February 27, 2015 - 08:24 am Edit Post Delete Post Print Post
David,

Can you explain why some DICOM Viewers--PACS and others, often are not able to display DICOM SR? Is there a technical hurdle?
 Link to this message David Clunie  posted on Friday, February 27, 2015 - 11:41 am Edit Post Delete Post Print Post
There are both business and technical obstacles:

1. "chicken and egg" problem ... not enough vendors (or users) producing it to justify the viewer effort

2. diversity of templates (structure of content) problem ... different ways to encode the same sort of thing (and different things), e.g., the content tree in an SR of a human authored "report" is organized differently than a modality produced OB or CV US collection of measurements ... should the "viewer" just dump the structure and contents regardless of template (ŕ la dcmtk's dsr2html, as used in Osirix), or render something "prettier" based on recognizing specific templates or patterns, and/or doing something "clever" with links to images (such as affect image viewer behavior)

Technically, building a basic SINR/TID 2000 template viewer is not that hard (if your toolkit has even rudimentary SR support), so I think the business justification issue is likely the greater hurdle.

David
 Link to this message Neelam Dugar  posted on Friday, February 27, 2015 - 05:07 pm Edit Post Delete Post Print Post
Thanks David.

We have asked VNA vendor to receive the report--both primary and addendums from RIS as an ORU and save them as a DICOM SR within the VNA.

1. This will allow us to migrate images and reports together--without extracts to be taken from RIS--(We had to take RIS extracts of reports as part of PACS migration in 2013). Hence, having a DICOM viewer with DICOM SR display capabilities becomes more relevant at the end of PACS contract for us. Improving data migration at the end of contract is important to prevent vendor lock-in and ensuring customer ownership of data.
2. It will also allow us to use a non-PACS viewer(with DICOM SR display) to display directly from VNA--the reports will be viewable too.
 Link to this message Shaun Smale  posted on Sunday, March 01, 2015 - 06:50 pm Edit Post Delete Post Print Post
Neelam
I am interested to know a bit more about you ideas for the addendum workflow. 
With DICOM is is common to close a study so as to prevent additional images being added after the report was made. It would be necessary to allow additional SR Objects (for the addendum) to be added. 
The challenge when displaying addendum on pacs is to ensure the addendum is displayed first (in order if more thn one). Important if the addendum was "I meant cut the left leg off, not the right" :-) 
How will the original SR report be superceeded with a replacement SR report containing the addendums, particularly if only the addendum is sent in the hl7 message? 
 Link to this message Neelam Dugar  posted on Sunday, March 01, 2015 - 10:09 pm Edit Post Delete Post Print Post
Hi Shaun,

VNA will receive the HL7 ORU from RIS.
It will convert the HL7 message into DICOM SR and store it with the DICOM images.
(we will test with a 3rd party DICOM viewer that can display DICOM SR to ensure that reports are indeed being stored--this is when we realised that many DICOM viewers do not display SR)
Addendum will be sent as ORU again and converted and stored as DICOM SR within VNA.
We will test this too.

I agree, for users the most up-to-date report must be displayed 1st. However, this is very much how the DICOM viewer will present the SR information---isnt it? Or have I mis-understood something?
 Link to this message Shaun Smale  posted on Monday, March 02, 2015 - 09:23 am Edit Post Delete Post Print Post
Neelam,
Are you suggesting that the viewer should organise the SR to display the addendum SR and the report SR in the correct order. I was thinking that there would be only one SR containing the addendum. The original kept as a version.
Either would work. like all these problems, it is a case of finding a solution that all the applications in a complex workflows can present a complete and consistent view, it usually boils down to the lowest common denominator.
 Link to this message Neelam Dugar  posted on Wednesday, March 04, 2015 - 03:03 pm Edit Post Delete Post Print Post
Hi Shaun,
Yes, viewer should be able to organise the DICOM SR reports in the order that users want it organised--ascending or descending date order.

Most of the addendums that I produce "add" information after MDTM discussions. They need to be read alongwith the primary report issued. Hence, the addendum cannot "replace" the original report. Many a time I will have put in 5 or 6 addendums, for a complex case that has been through multiple MDTMs.

I personally like to have the most up-to-date opinion first--but I know of other radiologists who want it the other way. So the viewer must be flexible. The DICOM archive component of VNS should be able to add DICOM SR, as they recieve the HL7 ORUs from RIS.
 Link to this message Shaun Smale  posted on Wednesday, March 04, 2015 - 03:40 pm Edit Post Delete Post Print Post
Neelam
The problem with addendum is that you do not know when, or even if, an addendum will be added. How can you be sure that all of the addendums are available to you. Would you consider a different work flow for addendum that provide additional supplementary information as opposed to those that correct the content of the main report. It is not generally acceptable to permit a report to be edited once approved and hence the need for an addendum. In this case would it be safer to produce a new SR with the report and addendum in the same file? The old SR would be kept as a prior version. The definitive audit responsibility remaining with the report source.
Shaun
 Link to this message Neelam Dugar  posted on Friday, March 06, 2015 - 03:18 pm Edit Post Delete Post Print Post
"The problem with addendum is that you do not know when, or even if, an addendum will be added."

Hi Shaun,
Above happens with PACS, EPR & result reporting systems today, and they deal with this uncertainty with no problems. VNA should be able to deal with it as well.
 
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users may post messages here.
Password:
Options: Automatically activate URLs in message
Action: