Device problems and user-related events reported for head-mounted augmented reality navigation systems in United States surveillance data

Design and data source

The study was a retrospective descriptive analysis of spontaneous medical device reports. Reporting followed the STROBE statement and its extension for routinely collected data.(26,27) The source was the open device adverse event endpoint of openFDA, which publishes the medical device reports received under the federal medical device reporting regulation.(28,29) Reports received between 2010 and 2023 were eligible. The endpoint is public, requires no login and was queried programmatically.

Augmented reality was defined as a system that combines real and virtual content, is interactive in real time and registers the virtual content in three dimensions.( 1) A report was eligible when its device was a component of such a system whose virtual content is shown on a head-mounted display, either a see-through headset or smart glasses. Mixed reality headsets were eligible under the same registration criterion. The search combined 34 queries on the narrative text, brand name and generic name fields. The terms covered augmented, mixed and virtual reality, head mounted, smart glasses, headset, glasses, heads-up display, holographic, exoscope and the abbreviation HMD, plus the brand names of the two systems that the first queries identified. Each query was paged at 100 reports with a date filter on the receipt date, and the pages were stored unchanged so that screening and analysis could be rerun on the same files. The endpoint returns narratives in upper case, and the scripts lowercased them before applying text rules. A further 33 count probes searched the three fields for six consumer and enterprise headset brand names and five generic headset phrases.

Screening used the device name, generic name and narrative. Reports were excluded when the match was lexical or incidental, for example an ophthalmic Latin term, a femoral head mounted on an implant, an audio headset or a catalog prefix. Virtual reality devices and video magnifiers without a see-through overlay were excluded because they are not augmented or mixed reality. The reasons for exclusion were counted by rule in the analysis script.

Reporting volume and source

The variables were the year of receipt, the year of the event, the report source code, the reporter occupation, the device operator and the remedial action. Manufacturers often file one report per device component for a single event, so a distinct event was defined as a set of reports sharing the first 200 characters of the narrative. Counts and proportions are presented per report and per distinct event, with Wilson 95% confidence intervals.(30)

Device component

The component was classified from the model field of each report, because the brand name was common to all reports of a system. Four classes were used: headset, computer and software, tool or pin adapter, and other system component. Reports for the same event were checked for mixed component classes. Counts were cross-tabulated against the system and the event type.

Event type and outcome

The event type was the value coded in the report (injury, malfunction or death). Under the reporting regulation, a serious injury includes an injury that requires medical or surgical intervention to preclude permanent impairment, and a malfunction is reportable when it would be likely to cause or contribute to a serious injury if it recurred.( 29) The FDA product problem codes and patient problem codes were tallied once per report. The outcome of each distinct event was coded from the narrative into five exclusive classes: neurological symptoms or deficit, implant placement corrected intraoperatively without harm, reference or registration problem corrected without implant revision, component detached or broken without harm, and bone fracture.

User-related events and attributed causes

The cause named or suspected in the narrative was coded for each distinct event into five non-exclusive categories: reference fixation, marker or camera movement; tool, screw interface, calibration or skiving; patient factors such as body mass, bone quality, anatomy and prior screw tracks; hardware component failure; and root cause not concluded. Reference fixation covered the clamp, pin, marker and camera that anchor the patient coordinate system. Tool, screw interface, calibration or skiving covered a loose or bent instrument interface, a calibration that did not follow the manual and the deviation of a tool at the entry point. A separate flag recorded a user-related cause, defined as user error, misuse or non-adherence to the instructions for use stated or concluded in the manufacturer narrative; a hedged mention of a possible user error was not coded. A text rule on the narrative terms checked the flag, and the number of events flagged by the rule but not coded is reported. Keyword searches counted narratives that described wearer symptoms, headset or display faults, and training or simulation settings.

Relations among dimensions

Two relations were specified before the data were examined: user-related cause by reference fixation, marker or camera movement, and neurological symptoms by patient factors. Each was tested with the two-sided Fisher exact test on distinct events, with the Holm adjustment over the two tests. Odds ratios used the Haldane-Anscombe correction and a Woolf interval. The analysis is exploratory and has no power calculation. Cross-tabulations of the five causes by user-related cause, implant correction and neurological symptoms complete the dimension.

Reporting volume and source

In the dimension reporting volume and source, the queries returned 490 distinct reports, and 44 of them (9.0%) described an augmented reality system with a head-mounted display. The included reports comprised 41 for the xVision Spine System and 3 for the NextAR system, grouped in 22 and 3 distinct events. The 18 probes on six headset brand names returned 0 reports (Table 1).

Reports presented a short history. The first was received in 2020, and none was received in the 10 earlier years of the window. The year 2023 obtained 21 reports against 3 in 2020, and the last two years concentrated 81.8% of the total (95% CI 68.0-90.5) (Figure 1).

Manufacturers filed 43 reports (97.7%) and a distributor filed one. Physicians were the reporter occupation in 38 reports. In relation to the other dimensions, 19 of the 25 events were filed twice with the same narrative, and no event mixed component classes (0 events). No narrative described training or simulation (0 matches), and all 25 described surgical procedures.

Device component

For this variable, the model field named a computer and software unit in 20 reports (45.5%) and a tool or pin adapter in 10. A headset was named in 7 reports, and another system component in 7 (Table 2).

Headsets obtained 15.9% of the reports (95% CI 7.9-29.4), and all 7 headset reports described injury events. Adapters concentrated the malfunctions: 8 of their 10 reports were malfunctions. The 11 distinct model names belonged to 41 xVision and 3 NextAR reports.

In relation to the event dimension, the narratives of the headset reports described screw misplacement after reference movement or tool calibration, and none described a display fault, a discomfort or a visual symptom (0 events matched the symptom terms). Headset or smart glasses terms appeared in 1 narrative, where the unit was reviewed without anomaly.

Event type and outcome

Within this component, injury events accounted for 34 reports (77.3%) and malfunctions for 10; no death was reported (Table 3). The problem code Use of Device Problem was assigned to 28 reports (63.6%), and the patient code No Clinical Signs, Symptoms or Conditions to 39 (88.6%).

At the level of distinct events, injury obtained 76.0% (95% CI 56.6-88.5). Implant placement was corrected intraoperatively without harm in 14 events (56.0%; 95% CI 37.1-73.3), and neurological symptoms were reported in 3 (12.0%; 95% CI 4.2-30.0). A component detached or broke in 5 events, and one event ended in a bone fracture.

In relation to the component dimension, hardware failure codes carried 5 of the 6 malfunction events, against 1 injury event. Recall was recorded as remedial action in 3 events, all of them adapter malfunctions.

User-related events and attributed causes

In the dimension user-related events and attributed causes, reference fixation, marker or camera movement was the most frequent attributed cause, with 11 events (44.0%; 95% CI 26.7-62.9). Patient factors followed with 9 events and tool, screw interface, calibration or skiving with 7. Hardware failure was attributed in 6 events, and 4 narratives stated that the root cause was not concluded (Table 4).

A user-related cause was stated in 9 events (36.0%; 95% CI 20.2-55.5), and all of them concerned the xVision system (9 events). The narratives stated explicitly that no system malfunction was found in 4 events. More than one cause was coded in 9 events, and the text rule flagged 1 hedged mention of user error that was not coded.

Within this component, no narrative described a wearer symptom, a display failure or a latency problem. The causes named the registration chain (clamp, pin, marker or camera), the instrument interface and the patient, and not the headset optics.

Relations among dimensions

In the dimension relations, user-related causes were stated in 7 of the 11 events with reference fixation or marker movement (63.6%) and in 2 of the 14 remaining events (14.3%) (Table 5).

The first prespecified test gave an odds ratio of 8.3 (95% CI 1.4-50.0; Fisher p = 0.017; Holm-adjusted p = 0.034). Neurological symptoms were reported in 3 of the 9 events with patient factors (33.3%) and in 0 of the 16 events without them (odds ratio 17.8; 95% CI 0.8-394.1; Fisher p = 0.037; Holm-adjusted p = 0.037).

Among the cross-tabulated causes, the hardware category obtained the lowest implant correction, with 1 of 6 events, and the category root cause not concluded the highest neurological share, with 2 of 4 events.

Reporting volume and source

The absence of reports before 2020 and the rise in the last two years follow the commercial life of the systems more than any change in safety. Surgical series with a commercial headset system started to appear in 2021,(7,31) and adoption reports run to 2023.(8,9) The same pattern, with peaks that follow adoption and learning, was found for the da Vinci system in MAUDE, where the proportion of console and cart malfunctions changed with surgeon experience and technology generation.( 32) Counting reports against time is therefore not a measure of risk, because no denominator of procedures is available.

The dominance of manufacturer reports shapes what is visible. Manufacturers file when their own investigation finds a reportable serious injury or malfunction, and the narratives in this record contain the manufacturer's investigation, including the statement that a redirected screw is a serious injury under the regulation. Clinical series reach the opposite impression. A prospective cohort recorded no intraoperative adverse events with the same class of system while revising four of 222 screws,( 8) and an accuracy series reported 98.5% of screws within the clinically acceptable zone.( 6) The two sources do not conflict, because a revised screw is a correction in a clinical series and a reportable injury in the regulation. Studies of MAUDE share this property, and reviews of the database find that most studies built on it are case series of poor quality, chiefly because of its structural limits as passive surveillance with free-text reports.( 23-25)

The window of the search also shapes the record. Research applications of general-purpose headsets, such as those in cadaver and visualisation studies,(33,34) are not marketed medical systems, and no manufacturer carries a reporting duty for them. A search of narrative text, brand and generic names finds a device only when its report carries one of the terms, and the probes for headset brand names returned none. The absence of reports before 2020 is therefore the absence of a regulated, marketed product with a surveillance obligation, and it should not be read as ten years of problem-free use.

The finding that no report described training or simulation is consistent with the regulatory scope. Mixed reality headsets are tested in training and surgical education,( 16-18) but a unit used to teach is not a patient-contact device and has no event to report. The absence of reports from training therefore says nothing about the safety of training with these devices, which is a reading the data do not allow.

Device component

Headsets were named in a minority of reports, and no narrative attributed the problem to its optics or display. This does not mean the headset is free of problems. Experimental work documents registration time that is longer in the operating room than in the laboratory and a strong influence of direct illumination on performance,(11) worse motor performance at higher display latency,(12) and ergonomic requirements on weight and balance.(13) Wireless headsets that remove head turning can still lengthen task completion, as in a randomised arthroscopy simulation.(35) The wearer's side of the device has also been associated with benefits, such as lower surgeon fatigue with smart glasses in scoliosis surgery.(36) A surveillance system built on device failure and patient injury is not designed to capture these effects, and a surgeon who finds the display tiring has no obvious route to report it.

The FDA problem codes show a second gap, which is granularity. The code Use of Device Problem was assigned to most reports, including events whose narratives state that the system displayed the tracked tool correctly and that the fault lay in the clamp, the calibration or the entry point, and the code Insufficient Device Problem Information was assigned to adapter malfunctions whose narratives describe the detached part precisely. Codes are chosen by the reporter from a fixed list, and the narrative carries the information that the code lacks. Analyses that rely on codes alone would classify these events as generic use problems, which is why the narratives were coded here. A framework that separates device problems from patient injuries, developed for orthodontic aligners, shows how a structured reading of the same fields can be organised.( 37)

Studies that measure the wearer's experience directly give a different picture from the surveillance record. A pilot of an augmented reality knee navigation system viewed through smart glasses assessed motion sickness with a questionnaire immediately after surgery,(38) and virtual reality sickness is documented across headset types and mitigated by specific strategies.(14,15) None of this reached the reports, which suggests that wearer symptoms are measured in studies and not reported as device events.

The probes for consumer and enterprise headset brands returned no report. Studies compare two mixed reality headsets for visualising radiological content and evaluate a successor model for orthopaedic oncological interventions,(34,39) and a cadaver study used a commercial mixed reality headset for pedicle screw navigation.( 33) These are research uses or uses of general-purpose hardware under a specific application, and a manufacturer of the hardware has no reporting duty for them. The consequence is that the systems most discussed in the literature are the least visible in the surveillance record.

Event type and outcome

The share of injury events differs from other MAUDE analyses. In robot-assisted surgery, about three-quarters of reports were malfunctions and 13.1% were injuries,(19) and in image-guided sinus navigation 97.1% were malfunctions and 2.9% involved patient adverse events.(20) Skull clamps showed 73.2% malfunctions,(22) and an analysis of angiographic equipment classified two-thirds of events as near misses.(40) In the present record, injuries predominated because the reports were driven by the manufacturer's rule that a screw redirected after a confirmation scan is a serious injury, and because most events were screw misplacement detected and corrected during the same operation. The harm reported was therefore mostly a correction, with no clinical signs recorded in the large majority of reports. Robotic arthroplasty offers a comparable picture, with surgical delay and conversion to manual surgery as the usual consequences and only a few reinterventions among the injuries.( 21)

The classification of an event as an injury deserves a caution. In most injury reports the patient code was No Clinical Signs, Symptoms or Conditions, so the injury category reflects the regulatory definition and not a clinical consequence. A reader who compares the injury share of this record with that of a record dominated by device malfunctions, such as the sinus navigation or skull clamp analyses,(20,22) would conclude that augmented reality navigation is more harmful, and the data do not support that conclusion. The reverse comparison is equally unsafe: the low injury share of robotic surgery per procedure was computed with a denominator of procedures that this record lacks.( 19)

Three events with neurological symptoms deserve separate attention, because they show that the correction of a misplaced screw does not always remove its consequences. One event ended in foot drop and revision surgery. In the other two, symptoms were reported as improving. The same range of consequences is described for robot-assisted placement, where unsatisfactory screws occur even in series with high accuracy.( 41-43) Malfunction events, in contrast, were adapter failures in which a spring, ball or trigger detached, with no harm reported. The comparison with robotic arthroplasty, where a retained registration checkpoint was the most frequent injury for hip procedures,( 21) suggests that fragments of navigation hardware left in the field are a recurring failure class across navigation technologies.

User-related events and attributed causes

Reference movement is the cause attributed most often, and it is also the best documented in the navigation literature. Navigation error grows with the distance from the dynamic reference frame and with vertebral motion from manipulation and respiration, with a mean error of 2 mm or more at two or more levels from the frame.(44) A drift phenomenon occurred in 16.7% of 341 deformity patients navigated with an intraoperative scanner, and the distance from the reference frame was an independent risk factor.(45) Perforation rates also rose with the distance from the frame in scoliosis surgery.(46,47) The narratives in the present record describe the same mechanism in clinical terms: a clamp not fully closed, a marker touching the skin, a bump on the pin and respiration during registration. This agreement suggests that the headset inherits the error structure of optical navigation, which the headset does not remove.

The failure of the clamp has a counterpart in other surgical fields. Slippage accounted for nearly half of the skull clamp malfunction reports in a ten-year MAUDE analysis, next to mechanical failure,( 22) and the unexpected movement of the robotic arm was the most frequent adverse event of robotic knee arthroplasty.( 21) In each case the element that anchors the patient to the navigation frame, or the element that moves relative to it, is the point of failure. The headset, which only displays the result, sits downstream of that chain, and an accurate display of a misregistered position would be reported as a use or registration problem, not as a display fault.

The patient factors in the narratives, namely high body mass, soft bone and prior screw tracks, coincide with some but not all of the literature. Obesity was an independent risk factor for unsatisfactory robot-assisted placement in one series,(41) whereas in a multicentre study obesity and other patient variables contributed little to the variation in accuracy.(48) The discrepancy may come from the outcome measure, which was unsatisfactory placement in one study and offset from the planned screw in the other, and from the system. The present record cannot arbitrate between them, because it has no unaffected cases for comparison.

Manufacturer attribution of the cause to the user needs caution. The manufacturer investigates its own device, and the narratives reach the conclusion of user error with different degrees of certainty. Other safety analyses find the same ambiguity. In machine learning devices reported to MAUDE, problems of use were 7% of events but four times more likely to cause harm,(49) and in da Vinci malfunction reports 18% of injuries were attributed to misuse by surgeon or staff.(50) Use errors tied to interface design are documented for electrosurgical units,(51) and a plea for manufacturers to assess rather than dismiss user complaints argues that device-use reports hide design signals.(52) The recommendation to mine MAUDE and recall data for use issues (53) applies here: the repeated clamp and calibration errors in the narratives are design opportunities, such as a closure indicator for the clamp and a calibration that detects a loose screw interface.

Relations among dimensions

The association between reference movement and user-related cause was the more precise of the two tests, and it survived the adjustment. It is partly built into the coding, because movement of a clamp that the surgeon left loose is a user-related cause by definition, and the manufacturer's narrative is the only source. The association with neurological symptoms was imprecise, with an interval that includes values from no association to very large ones, and all three events with symptoms had patient factors attributed. With 25 events, the tests are signals to be followed, in line with the use of spontaneous reports for signal detection and not for confirmation.( 54)

The coded categories are not independent of each other. A narrative that attributes the event to a loose clamp also tends to describe the surgeon's handling, and a narrative that attributes it to soft bone also tends to mention the pin. The cross-tabulation shows which categories coincide with user-related causes, implant correction and neurological symptoms, and it does not separate their effects. The hardware category stands apart, because it coincides with malfunctions without patient harm and not with screw correction, which supports the separation between failures of components and failures of the workflow.

Joint reading, strengths and limitations

Read together, the dimensions describe a safety problem of the navigation workflow carried by a headset, not a headset problem. The headset appears in the reports as a labelled component, and the events arise from clamps, pins, markers, instrument interfaces and patients. The inference holds only for the systems found.

The strengths are the transparent screening, the public source, the deduplication of events and the script that reproduces every figure. The limitations are specific. First, passive reporting and the absence of denominators prevent rates, and a procedure registry linked to the reports would allow them. Second, the narratives are written by manufacturers, so independent adjudication of a sample by clinicians would test the attribution. Third, 41 of 44 reports concern one system, and the findings should not be generalised to other vendors or to mixed reality headsets; surveillance of those would need searches by manufacturer and product code beyond the text terms used here. Fourth, a text search in a free-text field can miss reports filed under generic names, and the probes reduce but do not remove that risk. Fifth, the number of events limits the relations to exploratory status, and the Holm adjustment covers only the two prespecified tests. A related framework for structuring device problems and patient injuries in MAUDE, developed for another device family, offers a template for that repetition.( 37)

The practical implications come from the corrective actions stated in the narratives. Surgeons were instructed to close the clamp fully, to verify registration on a bone landmark and not on the skin or the tool, to re-scan after any bump or suspected marker movement and to follow the calibration method for swivelled instruments. Hospitals should add adapter inspection to the sterile processing routine, since several adapters at one site had damaged parts. For teaching, the record has a different message. The studies of headset-based training report feasibility and acceptance in small samples,( 16-18) and the surveillance record contains no training event. Programmes that adopt headsets for teaching should therefore define their own incident log, because the regulatory system will not capture it, and should include display latency, lighting and wearer symptoms among the items logged, since the experimental literature links the first two to performance loss and documents the third in headset use.( 11,12,14)

For Latin America, where hospitals that adopt these systems depend on local vigilance systems, the transferability of the record is limited: the content of local reports may differ from the federal reports analysed, and no regional evidence was analysed. Local registries of use problems that include the navigation workflow, and not only device failure, would give the regional view that this record lacks.