Neelam, a very interesting document that strikes a good balance between standards and a workable solution. As a consultant working for an AI vendor, the last thing we need are standards too onerous that stifle innovation and adoption. The idea of an AI gateway seems to me to be a sensible way to "manage" the proliferation of AI systems that seems an inevitability.
Heading off onto a slight tangent if I may, I have contacted someone of you here already regarding a Covid19 AI system for quantification of covid disease on NCCT. The system is a global initiative, is already live and is free of charge in an attempt to help tackle this terrible disease. Please contact me for further details if you think your trust would be interested. Thank you and sorry for the pitch but obviously I'm keen for this message to get out there urgently.
If this document was not being produced in the context of the current COVID-19, I would probably agree with most of it (except the reference to using DICOM Overlays in Images, which is a terrible idea, compared to DICOM SR and Presentation States). And I am all in favor of using standards, and the right standards.
But in a crisis, one should use anything one can get, and that includes burned in annotations in images, PDFs, drawings on a piece of toilet paper (if you can find any), etc. For example, though it is nice to turn annotations on and off on the original image, could one make do with burned in annotations in a screen shot shown side-by-side with the original? Of course. Would I reject an AI I could deploy today to help manage COVID-19 patients for that reason? Surely not, though I would expect it to be made more robust and interoperable later. Nor would I reject some crappy proprietary viewer in the interim, if it got the job done.
Also, I was surprised to see no mention of IHE. If you are going to use presentation states, consider following IHE Consistent Presentation of Images (CPI).
The IHE AI Results (AIR) profile is currently out for public comment, and specifically addresses the concerns raised in this RCR paper, for long term robust deployment, specifically requiring image displays to support SRs (esp. TID 1500), Segmentations, Parametric Maps, etc. to support AI result distribution. See:
As David Clunie said, pls look at the IHE profile out for public comment, which contains several recommendations I would make such as the encoding of results instead of using text; there is even a code for the specificity and sensitivity (DCM 111088 Case Sensitivity DCM 111090 Case Specificity).
Regarding the notification by a technologist to be "ready for AI", I can imagine also using DICOM Image Availability or MPPS instead of HL7.
One other minor thing: you talk about a PDF encapsulated SR, not sure what that means, it is either encapsulated PDF or a DICOM SR.
The IHE AI Workflow Profile, out for pubic comment, does cover the additional fields that are identified in this COVID-19 document. It includes a bit more. For example, identifying the actual AI procedure and the AI model performing the analysis. These may be simple ones to add.
One entry that I am curious, is with priority. We have heard that providing an update to the priority should be part of the message. Yet it was not included here. Any reason for that?
Everyone, please take a look at what IHE has put out for public comment. This is the time to impact the profiles.
The IHE AI Workflow (AIW) profile is currently out for public comment. The workflow does use DICOM UPS-RS for AI platforms, modality and PACS integration, but addresses RIS integration with HL7 messaging.
Many thanks All for your comments. Thanks David. We will look at the IHE profile and update the doc, when normality returns post COVID. We needed to get this document out ASAP, so that non-standards AI integration implementation in response to COVID pandemic does NOT become the defacto norm.
"Regarding the notification by a technologist to be "ready for AI", I can imagine also using DICOM Image Availability or MPPS instead of HL7." Good suggestion Herman. I will discuss with Vendors at the next RCR industry workshop.
In response to Chris: "One entry that I am curious, is with priority. We have heard that providing an update to the priority should be part of the message. Yet it was not included here. Any reason for that?" "Priority"--is the clinical priority set by the referring clinician.--how quickly should the scan be done and reported. AI will send out "Alerts" for prioritising reporting. Departments will decide which text classification sent in OBX5, need to be sent as alerts in OBX8 (for example "lung nodule" & "pneumothorax" will be text classifications sent in OBX5, but only pneumothorax will be an alert sent in OBX8.)
A human reporter takes into account many data items before considering which scan to report first 1. Patient Location--A&E, Ward, Outpatient, GP 2. Referring Priority 3. AI Alerts 4. AI classifiers (found) 5. Specialty of referrer 6. Modality are some key data items depending on what type of session we are doing (emergency Duty/On-call or Elective Reporting session) We use different filters at different times
Simon, I hope Behold AI can support the standards outlined by RCR
Dr Zhong Li
posted on Monday, April 13, 2020 - 04:33 pm
Excellent resources. Looking forward to seeing it is finalised.
A few quick questions/reflections in some recent deployments for Covid-19 etc if you don't mind:
1. Use case: Neelam's PDF mentioned 2 use cases - absolutely right - particularly the 2nd one (AI triage) seemed to be a quick start. A 24x7 available "little" AI module/component able to handle X-Ray/CT adhoc request and give quantified triage in seconds from A&E or PC etc settings do give quick benefits.
2. Maturity level and soft-landing: AI seems not to be a foundation business in healthcare yet; instead it's more an added-on value. It's at most a sub-£K business instead of £M. How could we lower the entry to help make them more sustainable in NHS playground for long-term benefits?
3. Regulatory: consolidated references are needed for help those small AI vendors. So far technical, legal and commercial are quite a challenge(understandable).
4. Test bench for an open community across NHS and beyond. Most "medical imaging specialty" AI services are built on open sources (otherwise I would be slightly cautious when deploying it for long-term sustainability) - what stops us (this excellent community) work together to set up an "open test bench" for i.e. this "Covid-19" challenge?
We have cloud/docker/interoperability etc tools at our disposal today - what stops the community to pool the anonymised images/data together, to enable various speciality AI components from various vendors/researchers running on top of it per a consolidated use cases, architecture, standards and regulatory that could be evolved the same time too?
With respect to the IHE AI Workflow; like other parts of IHE, it's great on paper, but what is important for practical implementation is its level of adoption - not just "on the sending side", but also from the PACS providers for the imaging, "on the receiving side". Like, for example, this cross site reporting workflow. Around since 2017 and not widely adopted and hence not currently usable.
The second thing I am really interested in is transporting image related information back into the PACSs. There is a DICOM Blended Softcopy Presentation State (BSPS). It is like the GSPS (which is reliably used now to transport overlays and anotation from one PACS to another). BSPS was designed to show PET imaging overplayed onto CT imaging in a way that is transportable (open) between systems. But it is a generic DICOM standard and could be used by AI vendors to export imaging in an open format a) if AI vendors are willing to export b) if PACS vendors are willing to receive (as per usual).
I would be interested to know if any AI vendors are considering or already using BSPS?
As I understand it, the primary goal of the AI Results profile is just that, to assure display on the receiving side for features that are currently poorly supported (and to constrain what is sent to be that which is renderable).
The PC draft of that profile does mention BSPS (see 4.Y188.8.131.52.6 Display of Parametric Maps line 1284), but its current mention is too wishy-washy to really achieve anything.
So in my initial comments I suggested that they drop mention of it from the profile.
But since you raise it, I have reconsidered, and perhaps it should be a named option with normative semantics. I will amend my comments accordingly.
The DICOM BSPS was designed primarily to help CT/PET systems indicate which PET images to superimpose on which CT images. Some of the use cases for it were combined with the DICOM Spatial Registration object (usually identity) in the IHE Fusion (FUS) profile.
Speaking of which, the FUS profile is probably worth reviewing in this context of AI results reporting and display. Sadly, there was not a lot of interest in either BSPS or FUS, and the latter never got out of trial implementation, but here it is for your reference:
I didn't think there was that much need for BSPS in the AI results profile, since as long as the SEG or Parametric Map images with the results are in the same Study and same Frame of Reference as the images to which they apply, the Image Display should be able to locate and render one superimposed on the other, +/- any volumetric reorientation/resampling required if not in the same plane with the same spacing (which I also think should be a separate named option, since reorientation/resampling may be challenging for many otherwise simple display systems). That has certainly been the CT/PET experience.
The BSPS would, however, allow explicit communication of the pseudo-color palette and alpha compositing value to be used in the case of the Parametric Map though (e.g., heat map of saliency or probability of malignancy).
I would certainly be strongly opposed to using the graphic and text annotation features of BSPS though, since that should be done using the SR with semantically meaningful structured results (just as SR should be used instead of GSPS/CPI, IFNOR than the codes are machine actionable).
PS. AFAIK, current support for BSPS by displays is non-existent, though many archives will store and regurgitate it.