FDA Posts New Draft Guidance on Computer-Assisted Detection Devices
It may be helpful to compare these new guidances with the pending MDDS rule, discussed here, in which the proposed rule defines an MDDS as Class I, the class with the lowest FDA scrutiny. Unlike MDDS, in the current case these CADe devices are not newly defined. However the FDA does acknowledge that the terminology may not widely known or used. A CADe system is not in the same class as an MDDS, and therefore is not an MDDS, because of the degree to which it analyzes medical device data.
The Federal Register posting defines CADe’s as “computerized systems that incorporate pattern recognition and data analyses capabilities (i.e. combine values, measurements or features extracted fro the patient radiological data) intended to identify, mark, highlight, or in any other manner direct attention to portions of the an image, or aspects of radiology data, that may reveal abnormalities during interpretation of patient radiology images or patient radiology device data by the intended user (i.e., a physician or other health care professional)”. As with the MDDS rule, it can be helpful to know what is excluded from the category as well as what is included. Here certain types of systems are defined to not be CADe. These include:
- CADx devices (which) are computerized systems intended to provide information beyond identifying, marking, highlighting, or in any other manner directing attention to portions of an image, or aspects of radiology device data, that may reveal abnormalities during interpretation of patient radiology images or patient radiology device data by the clinician. CADx devices include those devices that are intended to provide an assessment of disease or other conditions in terms of the likelihood of the presence or absence of disease, or are intended to specify disease type (i.e., specific diagnosis or differential diagnosis), severity, stage, or intervention recommended. An example of such a device would be a computer algorithm designed both to identify and prompt lung nodules on CT exams and also to provide a probability score to the clinician for each potential lesion as additional information.
- Computer-triage devices (which) are computerized systems intended to in any way reduce or eliminate any aspect of clinical care currently provided by a clinician, such as a device for which the output indicates that a subset of patients (i.e., one or more patients in the target population) are normal and therefore do not require interpretation of their radiological data by a clinician. An example of this device is a prescreening computer scheme that identifies patients with normal MRI scans that do not require any review or diagnostic interpretation by a clinician.
Market Trends Series #3: Shift from Dept to Enterprise Focus
From what I have observed over many years, Hospitals have historically approached medical device connectivity projects as a tactical issue to be dealt with. Up until relatively recently, technology alone could be used to solve the connectivity issue (i.e. getting data from point A to point B) with little to no negative impact on clinical workflow. Further, the scope of connectivity projects has been mainly departmentally focused and deployments have been relatively basic. By basic, I refer to projects that have focused on connecting one or two bedside medical devices to a single CIS application or EMR.
Evidence of all of this can be found by looking back at the past 10 or more years and examining typical implementations of biomedical device connectivity to information systems.
• Most implementations up to now have been in very specific care areas such as the ICU and OR.
• Most implementations are relatively small in scope, often in the area of about 20 to 50 beds. Incidentally, for most US hospitals this happens to be about the same number of ICU beds per facility.
• In the ICU, the key devices that are interfaced are typically multi-parameter patient monitors and sometimes ventilators – but vents to a much lesser degree than monitors.
• In the OR, the key devices are typically patient monitors and anesthesia/gas machines.
• Outside of high-acuity care areas, in the general ward there are some limited niche interface solutions for mobile vital signs data capture. Many of these are only semi-automated in terms of truly automating both the data capture and the clinical workflow.
• For virtually all of these implementations, the data collected from the devices is identified though a mapping of the medical device’s location – that is a bed or room location identifier is used to associate the data and alarms.
• The device workflow – that is the steps clinicians are required to perform at the bedside to interact with devices to establish connectivity – has been limited. This is because most of the devices are actually fixed to the location – i.e. the monitors in ICU are mounted to the wall and data is interface via a networked gateway with outbound HL7. Therefore few if any steps are required by clinicians because the devices are permanently tethered to a local PC or terminal server that facilitates the data collection.
But as discussed in some of my previous market trends postings – requirements for connectivity have been changing and in some not so subtle ways. Many hospitals are
