The value proposition of artificial intelligence solutions in healthcare have been well described1 and it is apparent that ‘narrow AI’ will have a role in every stage in the clinical workflow; in Radiology this means optimisation of every step in the pathway from the appropriateness of clinical requests for imaging2 to ensuring that recommendations from the radiology report are followed up.3
While there is great promise, with examples of successful AI implementation in single centres or most commonly in retrospective datasets, substantial barriers to implementation remain. Some of these are practical, others are more philosophical.
The first step is to identify which ‘narrow AI’ to focus on. For health systems embarking on clinical AI integration, criteria must be developed to narrow the scope of products under consideration. An example of some of these criteria are given in Table 1.
Any engagement of a third-party software provider to a health system begins with a comprehensive legal review. Groups developing AI solutions must classify their algorithms as medical devices for them to become used in routine practice, and as such should obtain CE marking in Europe or FDA clearance in the U.S. Until mid-2020 the level of CE marking obtained may be defined by the developers themselves, meaning that similar algorithms may be classified as Class I, Class IIA or Class IIB depending upon how they view their own product. In most cases, AI that assess ‘pixel data’ and may influence the physician is classed under ‘Rule 10’ as Class IIA Active devices and require external certification, whereas AI that influences the patient pathway (such as smart scheduling) is classified as Class I under ‘Rule 12’ (ce-marking.org) and may be self-certified. Unfortunately, this is not always consistent, so it is down to the healthcare system itself to review the documentation and decide whether the level of certification is sufficient. Even then, product may be certified for use on specific imaging systems, and this needs to be validated prior to implementation. From 2020, the new EU Medical Device Regulations will be enforced, necessitating far greater scrutiny of ‘software as a medical device’ (SaMD). Another key element of the certification is the intended use of the software in the clinical workflow; most AI developers are certifying SaMD as a ‘decision support tool’ ie it should not be used as a stand alone system. It is also important from a deployment perspective whether a clinician is allowed to use the software at the time of reporting or must use it only after the primary report is authorised (as a ‘second read’).
Once validated as a suitably certified medical device, a Data Protection Impact Assessment (DPIA) process must be undertaken to ensure that data privacy is maintained – in Europe this being the standard of the General Data Protection Regulations (GDPR). Alongside this is a Solution Architecture Review (SAR) which can be performed in parallel and scrutinises the proposed IT architecture. These may take several days and require on-site visits to the provider, to ensure the data processing pathways and physical environment is secure. Local rules must also be followed regarding use and storage of patient data, with every country interpreting the GDPR slightly differently. Privacy concerns and the requirement for a coherent digital infrastructure has been called ‘the inconvenient truth’ about AI in healthcare.4 Robust processes must also be in place to ensure that de-identification of personal data (if and when permitted) must take place before transmission to third parties.
The process of digital integration depends upon the maturity of the AI company and their product, the size and heterogeneity of the health system and the process by which data is transferred from provider to processor and vice versa. Mature companies with stable product may be integrated over a matter of days, but timescales get longer with heterogeneity of electronic systems (Hospital and Radiology Information Systems [HIS & RIS], Picture Archiving and Communication Systems [PACS] and Vendor Neutral Archives [VNA]) and data inputs (naming and standardisation of imaging sequences). When considering ‘pixel data’ AI (those algorithms concerning the images themselves rather than the workflow), data may be sent directly from the modality to be processed on a local server (‘on prem’) or transferred automatically to a virtual server for processing in the cloud (‘on the edge’). Alternatively, pixel data may be sent from the modality to PACS first, and then forwarded to local or cloud processing from there. Processed data is usually returned to the PACS for scrutiny, which necessitates integration with the PACS system itself. This is challenging across networks, unless there has been harmonisation not only of the PACS itself, but also the process of data coding and handling built within it.
Standardisation of data is as contentious in radiology as it is in any other branch of medicine, yet it is highly advantageous when it comes to data processing. Computer scientists would be delighted if imaging requests would be made using a clinical decision support system to ensure appropriateness, that the correct code is given to the procedure based upon an agreed standard such as RADLEX or LOINC.5 All similar procedures would be undertaken according to the same, agreed acquisition protocol (irrespective of vendor and model), and all reports would be structured in the same way using agreed terminology, for instance, RadReports.org from the ACR. Without these ideal conditions, it may be that complex mapping and integration has to be undertaken on a per-modality basis, even within the same health system. Depending upon the maturity of the algorithm, programme bugs may then become apparent due to heterogeneity of data input.
The use of each AI solution then needs to be taught to the community of professionals who interact with it; this may be fine for an AI developer who is training a small group but may be more problematic for a start-up facing training of a large health system. Even then, physicians may regard the solution with distrust unless proven to be completely accurate. One solution that we have adopted is to build a Radiologist feedback tool into the PACS interface, that allows clinicians to score the perceived accuracy of any given algorithm – in most cases check boxes with the legends ‘agree/ AI overestimation/ AI underestimation/ Both over and underestimation’ are sufficient to allow users to flag potential discrepancy that can be followed up subsequently.
Patients may have their data processed by certified medical devices as part of routine clinical practice with no additional consent required, however if the AI vendor would like feedback to improve the algorithm, specific data consent must be obtained from the patient prospectively. The right to share and use these data may also be denied post-hoc, meaning processes must be in place to identify those patients who have granted consent and to rescind it when necessary.
Once the practical barriers to AI implementation have been overcome, the question remains: Who pays for the AI? Pharmaceutical companies have become purchasers of AI systems used for the quantification of imaging biomarkers, but these tend to be used for batch processing in an offline setting. As yet, no national health systems or private health insurers have provided an additional tariff for the use of AI, meaning that space has to be found in already diminishing tariffs to support its introduction. While AI may hold the promise of efficiency gains and workload reduction, there has been no published evidence of this ‘in the wild’. Some hope comes from the development of specific patient-centric services that may be driven by AI-enabled insights, such as a bone health service in the UK which pays for the identification of patients at risk.6 In this instance the business case is made on the basis of the whole service rather than paying for a specific AI product as the early identification of patients at risk enables early intervention and downstream cost savings by reducing the number of subsequent fractures – an example of AI and value based health care coming together.
In less joined-up health systems, certainly those in which imaging services remain ‘component providers’ of care, local metrics will have to be obtained that justify introduction. For instance, improved accuracy of reporting, such as reducing the recall rate for women undergoing mammography7, improved reporting speeds and ultimately improved revenues. It will only be by trialling new AI solutions in multiple different healthcare markets, using all combinations of payor model, that widespread adoption will finally become possible.
1. Langlotz CP (2019) Will Artificial Intelligence Replace Radiologists? Radiology: Artificial Intelligence, 1(3):e190058.
2. Bizzo BC, Almeida RR, Michalski MH, Alkasab TK (2019) Artificial Intelligence and Clinical Decision Support for Radiologists and Referring Providers. Journal of the American College of Radiology, 16(9)Pt B):1351–6.
3. Lou R, Lalevic D, Chambers C, Zafar HM, Cook TS (2019) Automated Detection of Radiology Reports that Require Follow-up Imaging Using Natural Language Processing Feature Engineering and Machine Learning Classification. J Digit Imaging, 1–6.
4. Panch T, Mattie H, Celi L (2019) The “inconvenient truth” about AI in healthcare. NPJ Digital Medicine, 2(1):77.
5. Vreeman DJ, Abhyankar S, Wang KC et al. (2018) The LOINC RSNA radiology playbook - a unified terminology for radiology procedures. Journal of the American Medical Informatics Association, 25(7):885–93.
6. Bar A, Wolf L, Amitai O (2017) Imaging T-E. Compression fractures detection on CT. Proc SPIE 10134, Medical Imaging: Computer-Aided Diagnosis, arXiv:1706.01671. Available from spiedigitallibrary.org
7. Rodríguez-Ruiz A, Krupinski E, Mordang J-JJ et al. (2019) Detection of Breast Cancer with Mammography: Effect of an Artificial Intelligence Support System. Radiology, 29(2):305–14.